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1 USER^DEFINED DYNAMIC COLLABORATIVE ENVIRONMENTS 

2 This application is related in subject matter to and claims priority from 

3 provisional U.S. application serial number 60/101 ,43 1, filed on September 22, 1998. 

4 The contents of that application are bodily incorporated herein. 

5 BACKGROUND OF THE IWVErCEKffl 

6 1. Technical Field 

7 This invention relates generally to computer systems and networks. More 

8 particularly, the invention relates to systems and methods for providing user-defined 

9 collaborative environments for transacting business or electronic commerce. 

10 2. Related Iriforaatwn 

1 1 Following hurricane Andrew, many insurance companies sought to limit their 

12 risk by withdrawing coverage fiom coastal areas. While this made good sense for the 

13 specific companies, it was not acceptable from a societal perspective. The cities, 

14 towns, homes and businesses built near the coasts could not afford to go without 

1 5 insurance, nor could the financial institutions that loan ed money on these properties 

16 afford the risk. The problem facing the insurance companies was not the absolute 

17 magnitude of die ride, but the concentration of the risks in one area, leading to the 

1 8 possibility of very large losses resulting fiom a single event 

1 9 One taw firm had conceived the idea of providing a mechanism for insurance 

20 companies to exchange risk. Companies with a high exposure in one area (e.g. 

21 Florida windstorms) could reduce thetrriskby ceding part of this to another company 

22 with non-coincident risk (eg. California earthquakes) and assume part of the second 

23 company's risk in return. A company (CATEX) was formed to conduct such trading, 
2 4 but the trading rules had yet to be defined and the trading infrastructure had not yet 
25 been developed CATEX postulated that the key barrier to insurance risk trading was 
2 6 determining the relative risk of different perils in different regions. One approach 

2 7 suggested by CATEX was to try to estimate these relative risks (termed relativities) 

28 for a broad set of perils and regions, to provide an initial basis for trading. 

29 It was recognized, for various reasons, that this could not be done feasibly 

30 because: general estimates of risk, rather than the risk for specific locations, 

31 buildings, ships, etc. would be inadequate for commerce; there were many risks to 

32 evaluate given all of die permutations of location, perils, and structure; and 

3 3 companies would not be willing to trade risk based strictly on a third-party's analysis 

1 
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1 An analysis of the problem, however, indicated that estimating the relativities 

2 was not essential to facilitate trading, or, in a broader sense, that trading was the only 

3 way to address the problem of insuring concentrated risk. The key difficulty was 

4 determining how to create greater efficiency in the reinsurance market, whether by 

5 introducing new instruments (like swaps), bringing new capital to die market, 

6 connecting more buyers to more traders, or reducing the cost of placing reinsurance. 

7 It was determined that the above concept could be implemented in an electronic 

8 trading system that could play an important role in promoting these factors, and 

9 could, in fact, transform the reinsurance market, which is not very automated. A 

10 system that allowed trading was developed and implemented. A more detailed 

11 description of tins system, as enhanced in accordance with various inventive 

12 principles herein (referred to as "first-generation" complex instrument trading 

13 technology), are provided below. More generally, as electronic commerce (and 

14 business-to-business commerce,, in particular) has grown, various companies have 

15 developed software tools and services to facilitate transactions on the Internet and 

16 over private networks. E-Bay, for example, hosts a well-known web site that 

1 7 operates a transaction model (a so-called "concurrent auction") that permits buyers 
IB to submit bids on items offered by individuals. Lotus Notes provides a network- 
19 oriented system that allows users within a company to collaborate on projects. 
2 0 Oracle Corporation hosts various transaction engines for clients that pay to host such 

21 services on a web site. DIGEX Corporation similarly hosts web-based application 

22 programs including various transaction engines. Other companies sell so-called 

23 "shrink wrap" software that allows individuals to set up web sites that provide 

24 catalog ordering facilities and the like. 

2 5 Some Internet service providers, such as America Online, host "chat rooms* 1 

26 that permit members to hold private discussions with other members who enter 

27 various rooms associated with predetermined topics. A company known as 

2 8 blueonline.com hosts a web site that facilitates collaboration on construction projects. 
29 Various virtual private networks have been created to facilitate communication 

3 0 among computer users across the Internet and other networks, but these networks 
3 1 provided very limited functionality (e.g,, e-mail services); are not user-defined (they 
3 2 must be created and installed by system administrators); and they cannot be easily 
3 3 destroyed when they are no longer needed 

2 
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1 The aforementioned products and services are generally not welt suited to 

2 facilitating complex electronic transactions. As one example, most conventional 

3 services are predefined (not user-defined) and are centrally administered Thus, for 

4 example, a group of companies desiring to collaborate on a project must fit their 

5 collaboration into one of the environment models provided by an existing service 
€ provider (or, alternatively, build a custom system at great expense). 

7 Suppose, for example, that a group of high school students needs to 

8 collaborate on a research paper that requires soliciting volunteers for a survey on drug 

9 use, conducting the survey, brainstorming on the survey results, posing follow-up 

10 questions to survey participants anonymously, publishing a report summarizing the 

11 results, and advertising the report for sale to newspapers and radio stations. This 

12 project requires elements of communication among persons inside a defined group 

1 3 (those writing the paper) and outside the group (e.g., survey participants); conducting 

14 research (conducting the survey, compiling die results, comparing the results with 

1 5 other surveys published by news sources; and brainstorming on the meaning of the 

16 results); and conducting a commercial transaction (eg., publishing the survey in 

1 7 electronic form and making it available at a price to those who might be interested 

18 in die results). No existing software product or service is available to meet the 

1 9 specific needs of this research team. Creating a user-defined environment including 

20 tools and communication facilities to perform such a task would be prohibitively 

2 1 expensive. Even if such a tailor-made environment could be created, it would be 

22 difficult to disassemble the environment (computers, networks, and software) after 

23 die project was completed. 

24 In short, there is a need to provide a user-defined collaborative environment 

25 that is tailored to the needs of particular groups that conduct communication, 

26 research, electronic transactions, and deal-making. 

27 SUMMARY Off THE INVWmQB 

28 A first embodiment of the invention, referred to as a complex instrument 

2 9 trading engine (CITE), facilitates negotiation between two or more parties. En this 

30 embodiment, a set of negotiation tools and techniques such as anonymous email, 

3 1 secure communication, document retention, and bid and proposal listing services are 

3 2 provided in order to facilitate the negotiation and execution of complex instruments 
3 3 such as contracts between corporations, governments, and individuals. 

3 
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1 A second embodiment of the invention, referred to as a dynamic collaborative . 

2 environment (DCE), allows members of a group to define a dynamic virtual private 

3 network (DVFN) environment including user-selected tools that facilitate 

4 communication, research, analysis, and electronic transactions both within the group 

5 and outside the group. The environment can be destroyed easily when it is no longer 

6 needed. Multiple environments can co-exist on the same physical network of 

7 computers. 

8 Although the two embodiments are described separately for ease of 

9 comprehension, it should be understood that the two embodiments share many 

1 o features ami, in fact, the second embodiment could include some or all of die features 

11 of the first embodiment in a generalized collaborative system. Consequently, 

12 references to a specific embodiment in the following description should not be 

13 deemed to limit the scope of features or toots included in each embodiment 

14 Moreover, references to specific applications, such as the reinsurance industry, 

1 5 should not be deemed to limit the application of the invention to any particular field. 

16 MMEF DESCRIPTION OF THE DRAWINGS 

17 HO. 1 A shows a four-step model of deal making including meeting, analysis, 

1 8 negotiation, and closing the deal 

1 9 FIG. IB shows contract formation among a group of parties to a contract 

20 FIG. 2 shows a listing display system showing all offers for contracts and 

2 1 responses thereto. 

2 2 FIG. 3 shows details of a listing that has been selected by a user. 

2 3 FIG. 4 shows one possible implementation of a reply card definition screen. 

24 FIG. 5 shows one possible implementation of a document management 

25 screen. 

26 FIG. 6 shows one possible implementation of a screen indicating persons 

27 having access to a shared folder. 

2 8 FIG. 7 shows a list of consummated deals in the system. 

2 9 FIG. 8 A shows detailed information regarding a completed trade. 

30 FIG. 8B shows a deal summary including structured and unstructured 

3 1 information concerning the deal. 

3 2 FIG. 9 shows a "flip widget" in a first state. 

3 3 FIG. 1 0 shows a "flip widget" in a second state. 

4 
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1 FIG. 9A shows a more detailed example of a "flip widget" in a first state. 

2 FIG. 10A shows a more detailed example of a "flip widget" in a second state. 

3 FIG. 1 1 shows method steps that can be carried out to define, create, and 

4 destroy an environment according to a second embodiment of the invention. 

5 FIG. 12 shows one possible system architecture in which various principles 

6 of the invention can be implemented. 

7 FIGS. 1 3 A through 1 3C show one possible user interface for creating a group 

8 and identifying group members. 

9 FIG. 14A shows one possible user interlace for selecting group members from 

I o one or more lists. 

I I FIG. 14B shows one possible user interface for selecting group members by 

1 2 composing invitations. 

1 3 FIG. 1 4C shows one possible user interface for selecting group members by 

1 4 composing an advertisement. 

15 FIG. 15 shows a banner advertisement 1501 displayed on a web site, wherein 

16 the banner advertisement solicits participation in a group. 

7 FIG. 16 shows one possible user interface for selecting communication tools 

8 to be made available to group members. 

9 FIG. 1 7 shows one possible user interface for selecting research tools to be 

0 made available to group members. 

1 FIG, 18 shows one possible user interface for selecting transaction engines 

2 to be made available to group members. 

3 FIG. 19 shows one possible user interface for selecting participation engines 

4 to be made available to group members. 

5 FIG. 20A shows an authentication screen for group members to gain access 

6 to a newly created environment 

7 FIG. 20B shows a web page generated for a specific user-defined 

8 environment, including tools available to group members having access to the 

9 environment 

0 FIG. 21 shows one possible method of generating environments in accordance 

1 with various aspects of the present invention. 

2 FIG. 22 shows one possible data storage arrangement for storing and 

3 manipulating brain writing cards. 

5 
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X pETAIIED DESC RIPTION OF THE PREFERRED EMBODIMENTS 

2 A. COMPLEX INSTP J nyiKNT TRADING ENGINE EMBODIMENT 

3 A first embodiment of the present invention provides a second-generation 

4 version of a complex instrument trading system- The second-generation system 

5 includes specialized tools that were not included in the first version of the prior art 

6 CATEX insurance trading system described above. These tools represent a 

7 substantial improvement over the first generation and incorporate new concepts of 

8 communications in a trading environment, and other capabilities that did not exist in 

9 the first generation technology. In addition, it is believed that many of these tools are 

10 also applicable to software systems other than the Complex Instrument Trading 

11 Engine or Negotiating System (CITE) described herein. Thus, the inventive 

12 principles are not limited to trading systems for complex instruments, nor even to 

13 trading systems in general 

14 Primarily, the tools described herein ameliorate certain difficulties associated 

15 with trading of complex instruments. Complex instruments are instruments where 

16 there is more than one dimension for negotiation. As compared to such instruments 

17 as securities, complex instrument transactions take longer to research and 

18 consummate and require more extensive documentation. For example, stock trading 

19 employs a simple instrument (a share) and negotiation focuses on one dimension 

20 (price) while insurance contracts have many dimensions (term, price, coverage, 

2 1 definitions of perils, etc.). The stock market is relatively simple to automate - as 
2 2 soon as bid and asked prices match, the deal is concluded in an instant according to 

23 the rules of the exchange. Automation of complex trading is much more difficult, 

24 since the parties must negotiate and reach agreement on multiple dimensions and 

25 document that agreement using an instrument specific to the precise agreement 

26 Automation of complex instrument trading is more difficult in every way than trading 

2 7 simple instruments. 

28 The trading model behind the Complex Instrument Trading Engine or 

29 Negotiating System is built around a simple, four-step model of deal making. 

3 0 Referring to FIG. 1 A, the steps are as follows: 

31 l . Meeting : Potential buyers connect with potential sellers with reciprocal 

3 2 interests. This connection does not mean that a deal will necessarily be concluded but 

33 simply that die two parties have some basis for continuing discussion. In simple 

6 
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1 instrument trading, it is typically only necessary to advertise quantity and price 

2 offered or sought Offers for complex instruments must include substantially more 

3 detail and (frequently) extensive attachments or exhibits. 

4 2. Research/Analysis : Each company considers its own position and/or offer 

5 and the counter party's position. Using information and analytic tools from various 

6 sources, including internal resources and resources provided by or through the trading 

7 system, each party does research and refines its position. The multiple dimensions 

8 of complex instruments increases the analytical complexity and limits the value of 

9 a simple market price. As indicated by the arrows in FIG. 1, this step is usually 
1 0 performed iteratively with the negotiation. 

X1 3, Negotiation: Parties to die negotiation speak directly and exchange 

12 whatever information is necessary to advance the deal. As indicated by the arrows 

13 in FIG. I A, this step is usually performed iteratively with the research step. 

14 4. Close : the companies negotiate and sign an instrument that documents the 

15 deal. This can be a complete and detailed contract, or it may be a simple 

1 6 memorandum. In simple instrument trading, the actual trade agreement is often 

17 standardized by the exchange. In complex instrument trading, the agreement must 

18 be more specific to the deal, though it is possible to use such tools and fili-in-the 

19 blank forms. 

2 0 Within a system using these complex instrument tools, trading parties can 

2 1 place offers to buy, sell, or trade in a public area, and examine such offers ("listings") 

2 2 posted by others. Using advanced communications tools the parties can conduct 
2 3 initial discussions to determine if a placement is possible. Using tools described 

2 4 herein, die initial contact can be done anonymously. 

25 If a deal seems possible, the system preferably provides access to the 

26 extensive information necessary to assess the possible deal. This can include static 

27 information (e.g. reports or data) maintained within die system, links to information 

28 providers outside the system, online analytical tools, and links to providers of 

29 analytical services. 

3 o For complex instruments, the process of negotiating a deal is contemplated 
31 to be an iterative one, with successive stages of analysis and discussion. The need 
3 2 for extensive communication is one of the critical distinctions between trading of 
3 3 simple instruments (e.g. retail sale) and complex instruments. Complex instrument 

7 
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1 trading requires dialog and more - exchange of documents (often voluminous), < 

2 consultation with counsel and intermediaries* conferencing, and working together on 

3 the final agreement. For electronic commerce to have an impact in complex 

4 instrument trading, it must support and facilitate this communication, and not force 

5 trades to fall back on methods and technology outside the electronic trading 

6 environment 

7 The final step is closing the deal. The companies can negotiate a contract 

8 online. Tools provide sample, fill-in the blank contracts and memoranda of 

9 understanding as a starting point Negotiators can begin with these, or they can use 

10 one of their own. Collaborative software makes it possible to display text 

1 1 simultaneously on each negotiator's screen and to work on the language together. 

12 When the contract is final, the system allows for secure, online signature, though 

1 3 companies not comfortable with electronic signature for very large deals may print 

14 a hard copy and sign it conventionally. 

15 By creating electronic exchanges for complex instrument trading, the CITE 

1 6 tools can have a fundamental and positive impact on many areas of commerce: 

17 1. An electronic exchange makes it possible to put an offer in front of more 

18 people more quickly than could be informed through direct contact, even allowing 

19 for active intermediaries or brokers, 

20 2. Traders can advertise and conclude deals without the need for an 

21 intermediary when they have adequate support or internal resources, 

22 3. Through better communications, wider exposure for offers, and the first 

2 3 steps towards standard contract language, electronic trading of complex instruments 

24 can substantially reduces transaction costs. 

25 4. With lower transaction costs, it is possible to conclude deals that were not 

26 possible with higher overhead. 

27 5. Through the immediate posting of the results of trades, pricing is moved 

28 towards a market basis, reducing research and analysis costs enormously. This 

29 speeds placement 

30 6. Smaller exposure means lower risk, and market pricing is an adequate 

3 1 surrogate for analytically derived pricing in some circumstances. Together these 

3 2 factors make it possible for traders to participate in markets or market segments in 
3 3 which they would not normally do business. 

8 
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1 7. By making it possible for all companies, large and small, to talk directly. 

2 to each other, electronic trading of complex instruments can lead to the 

3 democratization of die marketplace increasing competition, 

4 Overall, electronic trading of complex instruments has the potential to 

5 improve the efficiency of markets enormously, and to establish markets in areas of 

6 commerce that are currently done through intermediaries or on a one«on-one basis. 

7 The trading tools described herein are designed to facilitate electronic trading of 

8 complex instruments. The first-generation complex instrument trading tools broke 

9 new ground in the extension of electronic commerce into new and more complicated 

10 markets. The table below summarizes the areas of new and improved technology, 

1 1 organized into the four steps of the general complex instrument trading model. 



Phase 



Meet 



First Generation 

Complex Instrument Trading 

Technology (PRIOR ART) 



• Operates on private 
network only 

• Post a listing to board by 
filling out a form 

• Display listing summary 
in a table 



• Search I istings by key 
word 



Post response to listing 
onboard 



Advanced 

Complex Instrument Trading 
Technology 



Establish 

communications with 
lister by following up on 
contact information in 
listings using 
unconnected 
communications tools 



Operates on private network 
or over the Internet 
Post listing to a board by 
filling out a form 
Listings and responses can 
have attachments and 
documents 

Display listing summary in a 
table, with sorting by tide, 
date, market type, buy/sell, 
or listing number. 
Search listings by keyword 
Register keywords with an 
electronic "agent" that 
monitors listings and sends 
notice of relevant new 
listings by Email 
Post response to listing on 
board 

Send private response 
(anonymously or with name 
attached). 

Response can be through a 
"reply card" designed by the 
trader posting a listing, to 
structure responses 
Direct connection between 
listings and communications 
tool 



SUBSTITUTE SHEET (RULE 26) 



WOOMTTO 



CA. 0234S241 2001-03-22 



Mi 

PCT/US99/21934 



Analysis 


• Internet access to 
research resources, on 
line and third-party 
analysis 


• Internet access to research 
resources, on line and third- 
party analysis 

• Research resources 
searchable using the same 
search engine and display as 
used for listings. 

• Online dialogs / user groups 


Negotiation 


• Requires private network 

• Directory of contact 
information for all traders 

• Connection between 
directory and Email 
client. 

• Directory not linked to 
other components of the 
system 

• Anonymous mail 
application providing for 
communications between 
two individuals 

• Anonymous mail 
delivered to mail client 

• No attachments for 
anonymous mail 

• No system for central 
repository of documents 


• Works on Internet or private 
network 

• Directory of contact 
information for all traders. 

» Direct connection between 
directory and Email client 

• Direct connection between 
directory and online 
conferencing software 

• Directory linked to listings 
and document management 
tool 

« Anonymous mail application 
providing for 
communications between 
individuals or groups of 
people working together 

• Anonymous mail does not 
require separate Email client 
software 

• Anonymous mail supports 
attachments 

• Internet-based system for 
distributions and sharing of 
documents. 

• Password and secure has 
protection for documents. 


Closure 


• Requires private network 

• Online signature of 
uploaded document 


• Internet or private network 

• Online signature of uploaded 
document 

• Registration /closure of deal 
through a fill-in form 

• Provision for digital 
signature and archiving of 
all documents associated 
with a deal 



Referring to FIG. IB, one aspect of the system within the framework of the 
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1 negotiation/analysis loop shown in FIG. 1, is the ability to define one or more 

2 contracts, for example, in the parlance of the reinsurance trade, "slip sheets. 0 Various 

3 members of a group of authorities modify the contract causing it gradually to Mkr a 

4 final fonn that is either rejected as untenable or accepted as a finalized deal. The 

5 system exposes various aspects of die contract and attendant documents to the 

6 appropriate participants in die transaction, also providing each with a level of 

7 authority to add, delete, or modify documents as well as the evolving contract or 

8 contracts (assuming there may be various contract templates being discussed). These 

9 filters (filter 1 through filter 4, for example), as shown in FIG. IB, determine the 

1 0 authority of the party (Party 1 -Party 4) to modify or see the data object, whether it is 

11 a document or a slip sheet. The system combines this system of filters with signature 

12 technology for closing the deal; that is, implementing signatures so that an 

1 3 enforceable contract is generated 

14 A deal is like any other data object and once it is defined and entered, it 

15 cannot be modified. Elements of the deal can be "signed" such as documents 

16 attached to a contract (for example, Contract 1 has documents Dl and D2 attached 

17 to (combined with) it Together these elements, the contract and the attachments, 

18 define the deal Also, the entire deal 245 can be signed using a signature device 

19 ("widget") S8. Other documents may relate to a deal but not be attached These can 

20 be viewed using a document manager described further below. 

21 Listing System 

22 Referring to FIG. 2, a listing screen displays all offers for contracts, for 
2 3 example offer 3 14, as well as responses to them, for example, response 3 13, The 

24 parameters of the offers and responses to them are shown in columns, the heading of 

25 each of which may be selected to sort the listings by that heading, for example 

26 heading 31 5 if clicked would sort by the unique iiKlex number for the listing. Notice 
2 7 that the responses (for example, response 313) are shown indented to indicate a series 
28 of elements of a dialogue-thread. As indicated, the responses have a "daughter" 

2 9 relationship to the parent listings. That is, listing 3 14 is a parent and reply 313 is a 

30 daughter. The daughters remain in their hierarchical position beneath the parent 

31 despite sorting by the column headings. This makes the tabular sort scheme 

3 2 compatible with a threaded display, which is useful to show dialogues. 

3 3 Referring now also to FIG. 3, when a user invokes a display of the details of 

11 
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1 a listing by clicking on an index hyperlink 312 Co show the details of the listing, a 

2 user interface element displays the lister's defined parameters of the listing. As 

3 shown, various parameters are displayed, many of winch are hyperlinked. For 

4 example, attachments 304 may be selected to display the corresponding attachments. 

5 A detailed description 301 may be provided as well as specific instructions for 

6 responding 302. A reply button 303 permits the user to reply. Activating the reply 

7 button 303 will either invoke a standard public reply screen which creates a new 

8 listing similar to the parent listing or a special reply defined by a reply card which is 

9 further described below. 

10 A reply to a listing can take the form of a public reply that invokes a screen 

1 1 substantially the same as FIG. 3 but with blank spots for entry of reply information. 

12 A more useful kind of response element is a reply card that can be defined by the 

1 3 lister* This is because in negotiations on complex transactions such as reinsurance 

14 contracts and, for example, pollution emission allowances, the parties with whom a 

15 lister would be willing to trade are limited in terms of certain criteria. These criteria 

1 € will vary from one type of transaction to another. 

17 In an active trading system, the number of listings can quickly grow to a large 

18 number and quickly exceed the number which can conveniently be displayed in a 

1 9 single table. Several capabilities are built into the system to address this problem. 

2 0 First, by default, listings are presented in order from newest to oldest. Second, the 

2 1 sort capabilities previously described allow users to modify the standard order. 

22 Third, the total market may be divided into subcategories. In the area of insurance 
2 3 catastrophe ride, these could include categories for different lines of insurance (e.g. 
2 4 marine, aviation, commercial buildings). Fourth, users may enter search criteria to 

25 identify a subset of listings of particular interest 

26 Searching listings; A user may enter a keyword such as "hurricane" to 

27 identify all listings that contain that word in the title, description, and (optionally) 
2 8 attachments. To improve the reliability of the search, users are provided access to 

29 a standard lexicon when composing a listing. In the first embodiment, this capability 

30 is invoked by pressing the right mouse button while the cursor is any field of the 

31 listing. A list of common tenns is displayed. The user can select the term of 

32 interest, which is thai placed into the text of the listing at the insertion point marked 

33 by the cursor. For example, a listing for insurance risk would typically include a 

12 
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1 field for geographic scope (i.e. die location of the properties to be insured). When 

2 in this field, the lexicon displayed would include terms such as "California" and 

3 "Coastal Florida". Choosing a term from the lexicon insures uniformity of 

4 terminology across listings and between the search engine and the listings. 

5 "California" will be used rather than a mix of "Ca", "CA", "Calif, etc. The search 

6 is further improved by syrnantic indexing. Essentially, this means that synonymous 

7 terms are grouped, so that searches for one will find the other. A person who 

8 searches for "California" will get listings for "Los Angeles" that do not include the 

9 word "California". 

10 The search engine can include an agent capability. This agent capability 

11 offers the user the option of saving a search, after the user reviews the results and 

12 deems mem acceptable. This search is retained in a library of searches along with the 

13 email address of the owner of the agent. The search is retained in the library until 

14 is it either deleted by the user when it is no longer needed or automatically deleted 

15 in a cleanup of searches older than a certain date. Whenever a new listing is placed 

16 on the system, all of the saved searches are executed. If the new listing meets any 

17 of the search criteria, a message is sent to the owner of that criterion via email or 

18 instant messaging. 

19 A model was developed to allow a lister to define a set of criteria and request 

20 a set of information from any respondents in the form of an anonymous reply "card.'' 

21 The card defines a set of requested information which may be packaged as a 
2 2 document object and placed in the document manager system and connected with 

23 each listing. A user would download the reply card and fill the card out and send it 

24 back to the posting parry. 

25 A document object, called a reply card, is made available to a respondent 

26 through the document manager. The respondent is permitted to retain his anonymity 

27 as is the lister. Each may communicate with the other through an Amail system 

28 described in more detail below. The respondent supplies the requested information 

29 and sends the data to the lister. A system in the listing manager allows a lister to 

30 define a reply card having any particular fields and instructions required of a 

31 respondent Some of the information required may be obtained automatically from 

32 a set of default data stored on the respondent's computer. 

33 Referring to FIG. 4, a reply card definition screen is invoked to define the 

13 
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1 parameters of a new listing* The new listing is defined using a user-interface element . 

2 looking much like FIG. 3. While the details axe not critical, the definition of reply 

3 card involves, in essence, the definition of a user-interface control such as a dialog 

4 with radio buttons, text boxes, etc. These are definable for server-side 

5 implementation through HTML and are well known so the details are not discussed 

6 here. The lister defines a set of controls that allow the entry by a replying party of 

7 the information that the lister requires. The reply card is stored as any other 

8 information object and may be organized and accessed through the document 

9 manager described below. FIG. 4 shows a simple example of a format of a reply 

10 card. 

11 A reply card is created by a user when posting a new listing. The lister 

12 specifies the information that must be included in a response, and the type of 

1 3 information object to display for the data element (e.g. a text box, check box, radio 

14 button). The system then creates an HTML page to collect the requested information. 

15 When a respondent clicks "Reply Card" on the listing screen, the page is displayed. 

16 All of the responses are automatically entered into a database created automatically 

17 when the reply card is composed. As each respondent fills out a reply card, a new 

18 record is added to the database of the system and the lister is permitted to view it 

1 9 through an appropriate filter as discussed above. 

20 Simatwfi gystm 

21 As business is increasingly done in an electronic environment, electronic 

22 signature and approval is becoming more critical. The typical electronic signature 

23 model has focused on two aspects: 

24 1. Electronic validation of the user - specifically determining that the person 
2 5 viewing a document on line is the authorized signatory; and 

26 2. Validating the document being signed by a means that either prevents 

2 7 modification of a document or will reveal whether changes have been made. 

28 Methods for validation of identity range from simple personal identification 

2 9 numbers or passwords, to electronic signature pads, and more advanced methods of 

3 0 biogenic validation such as fingerprint or retinal patterns. Methods for document 

3 1 validation range from simple archiving of one or more copies in a read-only model 

32 or inaccessible location to methods based on mathematical algorithms that create a 

33 characteristic number or alphanumeric string for a document. These strings are 

14 
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1 tamed "electronic signatures." Changes to the document change the electronic . 

2 signatures. Because the signatures are much shorter than the documents, very many 

3 documents have precisely the same signature, but the algorithms to calculate the 

4 signature are very difficult to invert, so that it is effectively impossible to deduce a 

5 meaningful change to a document that will preserve a specific signature. 

6 These two aspects of electronic signature are highly developed, but there has 

7 been little analysis or development of the general process by which documents can 

8 be signed 

9 The invention allows for secure and reliable routing of documents, for which 

1 0 signatures are required, to a specified list of signatories. Unlike prior art systems, 

11 such as ordering cm- accounts payable systems which have highly structured signature 

12 procedures tailored to a specific process, the present invention provides a flexible 

13 method and system that allows a signature-type of authority/requirement to be 

1 4 attached any kind of information object The method is sufficiently abstract, flexible, 

15 and general that it can be applied in many contexts aside from the CITE embodiment 

1 6 described in the present specification. 

1 7 One signature method/device employs the following steps: 

18 1. Registration amaforiW " This process provides a register of identifiers 

1 9 indicating entities with signatory authority and correlates these identifiers with the 

20 information objects for which the signatory authority is applicable. The same register 

21 may also be used to identify other types of authority in the system in which the 

22 signature device is implemented For example, document read authority, 
2 3 modification authority, exclusive access to documents, etc. may also be provided in 
24 the same register. Signature registration may be provided automatically in certain 
2 5 systems where registration of, for example, read/write authority is provided since any 
2 6 entity with signatory authority would in almost all instances, also be provided with 

27 some other kind of authority, most notably, read authority. Thus, where the signatory 

28 system is embedded in certain kinds of systems, it may be that no particular 

2 9 additional method or device is required to implement signatory registration since an 

3 0 existing register may already exist or be required for other purposes. 

3 1 Registration information includes the general categories of information listed 

32 below. Definitions of specific fields within these categories are a function of the 
3 3 specific implementation of the signature system or die parent system. The following 

15 
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1 are exemplary: 

2 1 . Identity - unique identifier of the entity, the organization^) with which the 

3 entity is affiliated, other relevant information. 

4 2. Contact information - information indicating how the entity can be 

5 reached, how documents and mail messages can be routed to the entity. 

6 3. Security Information - a password for each class of signature as described 

7 further below. 

8 2. Q\m$9 Qf afflatUTHL- The device/method provides a variety of classes of 

9 signature, each associated with a unique level of approval or level of commitment. 

10 For example, a class of signature-authority can be defined that represents 

1 1 individuals, for example, with authority to sign contracts only below a set amount, 

12 or for expenses relating only to one department of an organization, or within certain 

13 time constraints, etc. The signatory system mstintfling this taxonomy of possible 

14 signature types in a database with a unique identifier for each level of authority 

15 defined. The system allows the creation and deletion of classes. Each class is 

1 6 preferably permitted to be named and a descriptive definition attached to each class. 

17 3. Defining a Set of Signatures - Using an appmprtotA «c«r iWrfy^o -lfmmt, thff 

1 8 user of the system selects an information object (for example, a document, file, or 

19 collection of such objects) requiring signatures), The entity originating fee signature 

20 process then identifies the entity or entities required to sign the object. The 

2 1 specification of the signers can proceed either by the selection of individuals from a 

22 list supported by the above defined entity register. Alternatively, in an environment 
2 3 where individuals are strongly bound to organizations, for example, it can proceed 

24 by selecting the list of organizations that will sign and, within each organization, fee 

25 person who will sign. The list is built by a series of selections. After each selection 
2 6 from the list, fee user indicates his/her desire to add the selected individual to a list 
27 of required signatories. The user interfaces provides for entries in which all the 

2 8 selected signatories are required or only one of the selected signatories are required 
29 For example, if more than one entity is selected from the list prior to the 

3 0 selection (eg., clicking an "Add" button), the system may require a signature from 

31 any of the people selected, but not all of them. To require signature from every 

32 member of the group, the initiator may select one person, then "add", select the 

33 second, then "add", and so on. Thus, adding a group with one "add" command would 

16 
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1 provide an "any signature will suffice" list and adding members individually would 

2 require a signature from that individual or entity. Note that this technique may also 

3 be used to define combinations of required and "any of* groups. 

4 For each signer or group of signers selected in a single "add" command, the 

5 initiator of the signing sequence must specify the class of signature associated with 

6 the person for the document being signed This may be selected from a list of 

7 signature classes (see item 2). If the spetific implementation of the signature process 

8 only supports one class of signature, the selection of class may be omitted 

9 4. Rrod9m Of Sgial Onter Of Signgtore " After or concurrent with the creation of a 

10 signature list, the initiator specifies whether signatures must be in order or if a 

11 specific order is not required. For purposes of defining the order of signature, 

12 individuals who are selected as a group are considered as occupying a single place 

13 in the sequence. 

14 5. Document Authentication - Upon initiating a signature sequence; the information 

15 object is authenticated by means of a secure hash algorithm- The specific hashing 

16 algorithm is a matter of design choice or may made dependent on a user's choice. 

17 There are several possible hash algorithms available in the public domain. The 

18 electronic signature produced by the secure hash algorithm is archived with the 

1 9 information object in a secure repository. If the information object is, for example* 

20 a record in a database, the contents of the record are copied to a file in delimited 

2 1 format for archival purposes. If the object is a table, the table is exported prior to 

22 archive. 

23 6. ppemnent Routing - Upon initiation of a signature sequence, the initiator 

24 specifies how the signatories are to be informed The options are: 

25 • No notification from the signature system 

26 • Email message 

27 • Email message with attachment of the information object 

28 • Posting on a signature web site 

29 The system accepts and implements the chosen method, which may be connected to 

30 the signature or a single choice applied to all signatories. Alternatively, the method 

31 of notification may be stored with the signature class definitions. In a signature 

32 process with no required order, e-mail notice may be sent simultaneously to ail of the 

17 
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1 designated individuals at the time of initiation. If the process is serial, only the first 

2 parson may be notified. The electronic signature of the information object may be 

3 included in an e-mail message. 

4 7. AgggKing the gifwaffire SV«fim - The signature system can be implemented for 

5 access via a web browser or database client-saver software across the Internet, an 
S intranet, a LAN, or a WAN. Access to the system will typically require a password, 

7 but this may not be necessary on a secure network. Upon access to the system a user 

8 will have the option to display a list of all of the information objects which he or die 

9 has signed or is being asked to sign. For each object, the display can include the 

1 0 following information: 

11 • Object name 

12 • Description of object (text, mime, size, date) 

13 • List of scheduled signatories 

14 • Date each person signed 

15 • Class of signature for each person 

16 • Electronic signature produced by the secure hash algorithm 

17 If the object is available (viewable) on line, the display may also include a link to 

1 8 display or download the object. 

!9 8- Validation of the Object at Time of Signature - tfth* u**r Hnumf a«h c n T ^„ ^ f 

2 0 object, the system will execute the secure hash algorithm to calculate the electronic 

2 1 signature. This will be displayed so that the potential signer can compare it to the 

22 signature calculated at the time the process was initiated. If the user has previously 

23 downloaded the object or received it as an attachment to an Email, the user may 

24 access the secure hash code through the signature system and apply it to the version 

25 on the user's disk. 

26 9 Simm a POfflmqil - After the user has determined that an information object 

27 is authentic and that the contents merit signature, he or she can affix a signature by 

28 authenticating his or her identity. Various means of authentication may be used. The 

2 9 means of authentication may be at the discretion of die manager of the signature 

30 system. Such means may include personal identification numbers, passwords, 

31 authentication based on computer address or information stored on the signer's 

3 2 computer, third party validation using a public key or other security infiastructure, 

18 
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or biogenic (fingerprint-recognition, retina scan) methods. 

After a document is signed, the date of signature is recorded in a rintabnffft so 
that the display to other potential signers is updated. If the signature process is serial, 
the next person in the sequence is notified E-mail notice can be sent to all signers 
when the last signature is collected. 

1 0. Follow-up - At the time a signature process is initiated, the initiator can select 
a time (in hours, days, or a time or date-certain) for automated follow-up. If a 

8 document is not signed within (he specified period after notice, a follow-up e-mail 

9 can be sent as a reminder. Additional reminders may be sent at the same interval if 

10 the object has not been signed The reminders can be sent automatically by the 

1 1 system according to user-inpyt specifications* 

12 11. Cancellation - The initiator of a signature sequence can modify the sequence at 

1 3 any time, except that a signer can not be deleted from the list once they have signed 

14 an object. 

15 12. Transfer Of authority - The individual initiating a sequence can transfer the right 

16 to modify the list signature list to another individual in the system with appropriate 

1 7 validation of identity. 

18 Document Manager 

1 9 Successfully conducting commerce over an electronic network requires the 
2 0 exchange not only of messages, but of substantial blocks of information in die farm 

21 of documents and data. Beyond simply transferring files from hand to hand, it is 

22 often necessary for multiple parties to work on a document simultaneously or 

23 serially, to track changes, and to maintain a record of versions. Two general 
2 4 architectures have emerged for document management, which can be termed a "mail 
25 model' 1 and a "repository modeL" Under the mail model, documents are attached to 
2 6 messages and circulated person to person* Under the repository model, documents 

27 are placed in a central location. There are advantages and disadvantages to each. At 

28 a summary level; 



Mail Model 



Repository Model 
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1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 



Advantages 



Disadvantages 



Precise touting on a 
document specific 
basis. Push in the 
recipient is 
informed of a new 
document 
Coupling between 
document flow and 
a messaging. 
Dating is 
automatic. 



Creates multiple 
versions of a 
document, 
confounding 
configuration 
management and 
version control. 
Does not easily 
couple to online 
collaboration. 
Many mail savers 
limit size of 
attachment 
Relatively high 
effort to prepare 
messages. 



Compact storage — only 
one version of a file need 
to be stored. Natural 
group of files on die baas 
of subject or access 
group. Supports good 
configuration 
management and version 
control. 



Not push in the sense that 
users are automatically 
informed of new 
documents. Security 
model is more 
complicated than for 
email. Prior 
arrangement is necessary 
to access a repository. 



A browser-based document management model and tool combines the best 
features of repository model and the mail model, for document dissemination and 
sharing across the Internet or an intranet. 

Gcnqfll Architecture - The general architecture of die system combines two basic 
components: (1) a database of directories and documents and (2) a directory of users. 
The directory of documents lists documents (of any type) contained in the system, 
and folders that can contain documents or other folders. The directory of users 
contains a list of individuals and organizations that can access the system, with 
passwords and/or other information necessary to validate identity and to establish 
authority. 

Representation of document - The term "document" is used here in the broadest 

1 3 sense of any file that can be stored magnetically or electronically. Preferably, each 

14 file is given a unique name consisting of a string of no more than 256 characters. 

1 5 Preferably, the character set is limited to those members of the ASCII character set 
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1 which are displayable or printable. Thus, such codes as "escape" which have no . 

2 visible representation, would be excluded This is the file name that is displayed for 

3 purposes of identifying the document to the users. There is also an actual file name 

4 (which is not shown to users) to identify where copies of the file are stored in the 

5 central repository. Certain other information is kept in addition to the name of the 

6 file. This includes the following: 



7 1. Data of creation 

8 2. Date entered into repository 

9 3. Person who entered the document into the repository 

10 4. Description 

11 5. Size of the document 

12 6. Document type if known 

13 7. Date of last update 

14 8. Access password (optional) stored in encrypted form 

15 9. File folders) where the document appears 

16 10. Actual file name 



17 In addition to the above infonnation, data indicating whether the file is 

1 8 checked-out and to what entity, and the identities of entities that have checked the 

1 9 document out and returned it in the past are also stored. The tarn "checking out" is 

20 described further below. These functions related to file change control and 

2 1 configuration management, which are discussed later. 

22 Vgey dafoftase.- A database contains information on all individuals who can currently 

23 access the system or who previously had access up to an administratively determined 

24 retention period This database includes standard contact infonnation including 
2 5 physical and electronic addresses. Security data such as passwords and/or encryption 
26 keys is also maintained. In a combined system such as the presently described 

2 7 system, the same database or registry of users can be employed for the document 

28 manager as for the signature system. 

29 flighteYSl ftrectongs ~ ^ e document management system can be divided into 

30 a number of high level directories that die user can display, one at a time. These 

3 1 include, at a minimum, a "Private" directory of files and folders visible only to the 

32 user, and a "Public" directory of files and folders visible to all users. Additional 

3 3 high-level directories can be created by the system administrator as needed. These 
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1 coald correspond to projects, business units, or any otter logical basis. At any point 

2 in the use of the document management system, a user can see and select from the 

3 high level directories to which the user has access. The name of the currently open 

4 directory can be always displayed on the screen. 

5 Displaying the contents of a high-level directory - When a user selects a high-level 

6 directory, the repository displays a series of file folders against die left margin of the 

7 active window. File folders whose contents are displayed are shown as open folders. 

8 File folders who contents are not displayed are shown as closed folders. A folder is 

9 opened or closed by clicking a single time. When a folder is opened, the contents are 

1 0 shown with an indent to indicate die parent/child relationship between the folder and 

11 its contents. Each folder can contain files, shown by an icon representing a printed 

1 2 page and other folders, represented by an image of a closed folder. 

1 3 Information about a folder - Information about each folder is displayed on the same 

1 4 line, to the right of the folder icon* This information is as follows, from left to right: 

15 1. Name of the folder 

16 2* Number of files in the folder, or the word "empty" 

17 3. Accessibility of the folder 

1 8 Accessibility refers to user access rights to a folder which may private relative to the 

1 9 entity that created it, restricted (limited to a subset of people who can access the high 

20 level directory), or shared (available to everyone with access to the high-level 

2 1 directory). The level of access to a directory is indicated by the words "private", 

22 "restricted 11 or "shared." 

23 If die directory is restricted, clicking on the word restricted displays a list of 

24 the entities that have access to the folder. This list is a series of hyperlinks. Clicking 

25 on the name of a person pulls up detailed contact information (discussed below). The 
2 6 objective is to facilitate communications between people with a shared interest in a 
27 file. 

2 B Igfermfttipn f&PHt ft fflff - Information about a file is displayed to the right of the file 

2 9 icon. From left to right, the first item displayed is the name. This is followed by the 

3 0 word "details " Clicking on "details," causes the document management system to 

31 display complete information about the file (see Item 2, above), the person who 

32 placed the document in the file, (see Item 3, above), and the person who most 
3 3 recently modified the file. 

22 
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1 fafonrattton PWPlc/entittes. and the link to comrminir^nn, , Information. 

2 about people/entities with access to the system is displayable at several points in die 

3 document manager system: 

4 1. by accessing the directory of users 

5 2. when creating a new folder with "restricted" access 

6 3. when displaying detailed information about a file (see #7) 

7 4. when displaying information about a restricted directory (see #6) 

8 Whenever such information is displayed, contact information from the database is 

9 rendered along with the name. Depending on the implementation, this can include 

10 complete contact info (multiple addresses, telephone and fex numbers, and email 

11 addresses), or some of the contact information may be restricted, in which case it is 

12 not displayed. 

13 Creating ft new top \$y?l f$\fa - a new folder is created within a high-level 

14 directory, for example by clicking a button labeled "new folder." This can bring up 

15 a dialog in which the user assigns a name to the new folder and selects the type of 

16 access (private, shared, or restricted) rights to be assigned. If the document is 

17 restricted, the user specifies the entities (organizations and/or people) that can access 

18 the folder. If the creator of die folder specifies that an organization has access to a 

19 folder, all individuals associated with that organization may be granted access. 
2 0 Folders to which a user does not have access may remain hidden or not displayed. 
2 1 Alternatively, these folders can be shown with some indication that they are not 
2 2 accessible, for example, by ghosting. 

23 Functions related tn a frUfler - Once a folder is defined, a user can execute the 

2 4 following options. 

25 1 # Create a subfolder, using the same process described in 9 

26 2. Add a document to the folder, using the process described in 1 1 

27 3. Delete the folder, if it is empty 

28 4. Modify access to the folder using the same tools used to specify access 

29 initially 

30 The functions can be invoked by, for example, clicking on the appropriate label to the 

3 1 right of the name of the folder icon. 

32 Atiflfflg 3 - Users add a document using a dialog box that prompts for the 

33 following information: 

23 
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1 1. Location of file -may be entered by user, or selected through a standard 

2 file browse dialog 

3 2. Name to be used for the file in the repository 

4 3. Version number or name (optional) 

5 4. Password or encryption key (optional) 

6 5. Description (optional) 

7 6. Access rules (read only or read-write) 

8 After entering the above information, the user either aborts or initiates upload. 

9 The information listed above is recorded along with the name of the person entering 

10 the document, and date and time. 

1 1 File options- The following functions may be provided* preferably for every file in 

12 the system: 

13 1 . Delete (with confirmation) 

14 2. Archive. The file is removed from main repository, but a copy is retained 

15 outside die repository. It may be restored though manual intervention. 

16 3. View or download: a copy of the file is brought to the user's computer. 

17 This file can be modified there for the individual user's use. A modified 

1 8 version can be uploaded as a new file or different version of a current one, but 

19 a file in the repository can only be replaced if the user has it checked out 

20 4. deck out / check in (see below) 

21 5. Forward (see below) 

22 6. Change Password The old password must be entered followed by a new 
2 3 password and confirmation. 

24 7. Move: copy or more a document from one folder to another. 

25 The functions may be invoked, for example by clicking on a label 
2 6 corresponding to the function, which can be displayed to the right of the name of the 

27 file. Not all options are shown to all users. If an entity does not have write-access 

28 to a file, the entity may not delete it, archive it, check it in or out, or change the 

29 password 

30 Check in / Check Out * All entities whh write access to a file may check it nut By 

3 1 checking the file out, the entity reserves the exclusive write to save changes to a file, 

32 A person may not replace a file that is checked out. To check out a file, the user 

33 selects this option from the list of functions associated with the file. The user can 

24 
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1 then enter an expected return date and a reason that the file is checked out or the . 

2 changes to be made. This information is available to all others who can view the file. 

3 Each check in or check out is recorded in a permanent log. After a file is checked 

4 out, the "check out* button or link is changed to read "check in." 

5 Each individual can check in only the files that he or she has checked out 

6 This is done by clicking "check in/ The user may then upload a new version of the 

7 file by specifying the location of the file on disk, or indicate that the version of the 

8 file currently in the repository is to be retained After a file is checked in, the check 

9 button is changed back to "check out" and the file can be checked out by another 

10 user. 

11 Forwarding - A file can be forwarded to any other user of die system* When the 

12 forward function is invoked, a list of users is displayed The sender selects one or 

1 3 more users. Upon confirmation, a copy of the document is placed in folder labeled 

1 4 "in box" in each recipients private directory. 

1 5 Referring to FIG. 5, a main screen for die document manager creates (using 

16 server-side scripting) a user-interface display with some of the features of a Windows 

17 Explorer® -type display. File and folder icons are shown along with an array 

1 8 features arranged next to each- The similarities with Windows Explorer® feirly well 

19 end there, however. Each of the properties shown next to each file/folder entry 
2 0 invokes a feature. 

21 A parameter object W "Details" invokes a detailed display of die 

22 corresponding document object. The details can include contact information about 

23 the creator of poster of the document or other data as desired This data can be 

24 hyperlinked and a return button can be provided to return the display back to the 

25 screen shown in FIG. 5. Clicking the "details* button to the right of any document 

26 brings up the diq>lay which can include the name, contact information, and other 

27 details about the person who loaded the document into the system, similar 

28 information about a person who has the document checked out, and, optionally, a 

2 9 description of the document and information on its change history. 

3 0 A parameter object X "Forward" simply sends the document to a selected 

3 1 user. A selection screen can be invoked to allow selection of the recipient of the 

32 document from die user registry. Of course, since most correspondence can be 
3 3 handled on the server side, the user is, in reality, simply notified of the transfer and 

25 
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1 the recipient's action to view the document simply invokes a saver side feature to . 

2 display the document The document is not actually transferred bodily to the 

3 recipient since the recipient, as a registrant logged in the user registry, can access it 

4 through the server by requesting to do so. 

5 A parameter object U '^Check-in" checks in a document that has been checked 

6 out Other users may view the document, but not modify it when it is checked out 

7 This button is not accessible to users that have not checked the document out and 

8 may be displayed ghosted or not displayed at all. A similar button can be displayed 

9 if a document that is not checked out may be checked out by the user authorized to 

10 see die document manager displayed shown in FIG. 5. 

11 A parameter object T "Download" actually transfers a copy of the document 

12 to die client computer. Another object S "Delete" allows the document to be deleted 

13 A new document can be added by clicking "New Document" Q. These are fairly 

14 conventional notions, except for their placement on the screen and the feet that each 

15 is filtered depending on the user*s rights. 

1 6 Note that when a folder is created, access to the folder can be restricted to the 

17 creator, shared with everyone (in which case the folder is created in die public 

18 directory), or shared with a select group of other users. The other users can be 

19 selected by company or organization (providing access to all individuals in the 

20 organization) or by individual within an organization. These are all selectable 

2 1 through a linked selection control where if one selects a company in one selection 

22 control, it show employees in the linked selection control. 

23 A parameter object P "Shared" displays a hyperiinked page that shows all 

24 users with access rights to the document This page allows a user that places a 

25 document in the document manager or a user thai has pertinent modify rights, to alter 

26 the parties that have access to the document Also, it allows a user with read-only 

27 rights to see the list of users that can access that document The names of the sharing 
2 6 parties are hyperiinked to invoke the user's email client to allow fast sending of email 
2 9 (which again may be performed saver-side without actual transfer) or conventionally 

30 or selectively. If a folder is shared, die word "Shared" appears to the right of the 

3 1 folder. Clicking on "Shared" brings up the list of person who can access the folder, 

32 as shown in FIG. 6. Each name is a hyperlink to detailed contact infonnation. 

33 FIG. 7 shows a list of all deals that were completed through the system. The 

26 
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1 trade number (left column of the grid) is a hyper link to detailed information. 

2 FIG. 8A shows detailed information about a completed trade. It shows die 

3 party to the trade, die price or rale, and a description of what was traded. The 

4 particular nomenclature is specific to a market For insurance, for example, price is 

5 termed rate, and the summary of a deal is the slip sheet A complete contract can be 

6 attached. Included documents can be downloaded to view on line. The intended 

7 signatories to a deal are shown (there can be more than two). 



8 If a signatory has actually signed the document electronically, the date and 

9 time are shown. No date and time are shown for parties that have not yet signed. 

1 0 The amount of information displayed on the screen is dependent on the identity of 

11 the person viewing the screen. The viewer can be blocked from viewing any 

12 information about a deal, or certain fields, such as the contract details or the name of 

13 signatories. 

14 Note that the detail screen of FIG. 8A would also show attached exhibits. The 

1 5 HO. 8A display is the basic device for signing deals. A similar device would be used 

16 for signing documents. 

1 7 Referring to FIG. 8B, all of the information necessary to document a deal is 



18 pulled together through the screen below. The deal summary includes highly 

19 structured information on parties, dates, terms, etc., as well as unstructured 

20 information in the form of attachments. The bottom part of the page allows the 

2 1 person registering the deal to designate the intended signatories. When the signers 

22 affix their electronic signature, they are doing so to all of the documents in the deal, 
2 3 including the attachments. These are archived and protected from tampering using 
24 secure hash technology. In this way it is possible to create a reliable, on line 
2 5 electronic signature to a complex deal, without risk of repudiation. 



2 6 Note that any number of exhibits can be added to the UI device of FIG. 8B 

2 7 since the list scrolls from the bottom each time a second exhibit is added. The user 

2 8 interface has self-explanatory elements for defining information about the deal 

29 Anonymous Mail 

30 For purposes of the following description, a "subscriber" is a person or entity 

31 that subscribes to an anonymous mail system to be described below. Certain types 

3 2 of negotiations and communications require anonymous initial contact followed by 
3 3 some period of anonymous discourse, leading to eventual disclosure of the parties 1 

27 
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1 identities. In the course of a typical sale or business deal, th C initiating party begins 

2 either by contacting one or more targeted potential trading partners or advertising to 

3 a community of potential partners. While the identity of the initial offeror is usually 

4 clear in any direct contact, it need not be so in advertising. In certain cases it could 

5 be problematic for the initiating party to reveal his or her identity: 

6 A party to a deal can have difficulty controlling the method of contact once 

7 the party's identity is known. If a company is known to be in the market for office 

8 space, for example, the party may be subjected to badgering by real estate firms 

9 outside the established bidding process. Executives of the company may be contacted 
10 directly in an effort to influence the decision. 

H Disclosure of intent may adversely affect the market If a large company 

12 begins to acquire land in an area, the price can rise very quickly. Simple exploration 

13 of an option can make the Option more costly or even impossible. 

14 Disclosure of intent may adversely impact the reputation or standing of a 

15 company. An insurance company that determines that it is over exposed to a certain 

16 peril (e.g. hurricane losses in the Southeastern U.S.) would reveal that situation to 

1 7 their competitors and investors by a large public solicitation. 

18 While anonymity can be crucial for the initiator of a deal, it can be equally 

19 important for the respondent for the same reasons. The need for controlled anonymity 

20 has been addressed by several methods that were initially developed tor paper 

2 1 communications and have been extended to analogues in telephonic and computer 

22 communications. 

23 • Numbered mail boxes, including government and private 

24 • Communications through a mediator 

25 • Anonymous voice mail drops 

26 • The use of pseudonyms in computer e-mail and dialogs. 
2 7 These methods have several serious shortcomings: 

28 • The method may only allow anonymity from one side. 

29 • There is no inherent mechanism to validate the credentials and intent 

30 on an anonymous party 

31 , Use of a pseudonym may invalidate its future use by associating the 

32 name with a specific party 

28 
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1 • Manually mediated communications are slow 

. me creation and deletion of pseudonyms may not be completely 

3 within the control of the party, imposing an overhead cost (in cash or labor) 

4 and/or delay in creating a new name 

s . In most systems, a person with multiple pseudonymous mailboxes or 

6 e-mail addresses will receive cornmunications in several different places 

7 (ma iIboxes or accounts), thus requiring multiple logons/passwords. 

8 . Routing of messages received anonymously requires manual 

9 forwarding to all relevant parties by the individual with access to the 
10 anonymous mail box or email account. 

1L . There is no mechanism to reveal actual identities in a secure and 

12 mutually acceptable way, 

13 The present invention addresses these deficiencies by providing two-way 

14 anonymous communications, a central pomt of collection for messages sent to 

15 multiple pseudonymous addresses, connection of multiple parties to a smgle 

16 anonymous ac^t, and a mecham^^ 

17 simultaneously, by mutual consent In summary, the anonymous mail system is a 

18 server side system that allows clients to create anonymous handles on the fly. It also 

19 auows them to share anonymous handles among multiple recipients so that the group 

20 ofrecfrientsappearcasas^ 

21 h is like a transparent mailing group. When mart is sent to an anonymous handle, * 

22 is sent to all members of me group. 

present system allows for multiple anonymous mail (Amail) systems. Each Amml 
system operates in association with a conventional e-mail server, and uses the e^ul 
server for communications with non-subscribers, subscribers to Amail systems other 
than the local one. and for forwarding messages to the subscribers Email client 



23 
24 
25 
26 
27 

28 software 
29 



Bs ^ Ss ^ r Subscribers to an anonymous mail system (Amail) each complete a 
3 o registration that provides: 

31 . Contact information (name, address, telephone number, fax, etc.) 

32 . Information to determine whether they the party is qualified to 

29 
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1 participate in the commimiaitions exchange. For example, if the system were 

2 to be used between and among real-estate agents, registrants to the system 

3 might be required to supply a real estate license number. 

4 • Association with an organization (if appropriate) 

5 • Additional infinmation on the individual or organization that may be 

6 ofuMtootheistotfaeAmaUsystOTtod* 

7 as a partner in negotiations. 

8 The additional information can include such factors as credit ratings, assets, or the 

9 region in which the company does business. The specific information required 

10 depends on the application. Insurance, real estate, energy marketing, etc. would all 

1 1 have different data of interest 

12 Validation - Depending on the business model and role of the organization operating 

13 the Amail exchange, the organization can either accept the information provided by 

14 the subscriber, or verify the information and provide verification as part of the 

15 service. Upon acceptance of a subscription applications and validation of the 

16 background information if necessary, the use is assigned an Amail user ID and 

17 password. 

18 In the first version of the Amail system, logon was automatic from the general 

1 9 application (CATEX); there was no separate user ID and password. In alternative 

20 versions, the Amail system can provide its own user ID and password, with the 

2 1 ability to bypass logon when it accessed from other applications with acceptable user 

22 validation. All of the actual contact information and validation information are 

23 maintain ed in a database. Validation information was not provided in the first 

24 version of CATEX. 

2s Alignment of an Email address - Each subscriber must provide an Internet 

26 accessible Email address or be assigned an e-mail address in the Amail system. The 

27 first version of the Amail required that the user have an Email address on the system. 

28 The new version works directly with e-mail systems other man the Amail. 

2 9 Logon- Subscribers access the Amail system by connecting an Amail web page 

30 provided either over the Internet or on an Intranet The subscriber enters a user name 

31 and password The first version of Amail was not browser-based and worked only 

32 over a LAN or WAN, not over the Internet or an intranet. 

30 
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1 Amiable functions- After logon, the subscriber can access the following tactions: 

2 • Manage aliases 

3 • Compose an anonymous message 

4 • Read Amail messages. In the original CATEX system, the user could 

5 not access messages from within the Amail application. 

6 ♦ Log off 

7 Managing Aliases- Aliases are directly under user control. After logon, a user can: 

8 • Add a new aliases 

9 • Delete an existing alias 

10 • Create a free-form note associated with a new alias, or edit die note for an 

1 1 existing alias that will be accessible to recipients from the alias. 

12 • Identify other subscribers to whom messages to alias should be forwarded 

13 • Identify other subscribers with parmission to generate messages from the alias 

14 These last two features make it possible for a group of subscribers to share an alias, 

1 5 allowing them share communications and work together more effectively. The user 

16 will: 

17 ro m?Qse an anonymous message - After logon, a user can create and send an 
IB anonymous message. After the option is selected, the system will display a message 

1 9 creation screen with the following features: 

20 1. A list of aliases currently owned by the user (Le. created by the user and 

21 not deleted), for the user to select the alias from which the message will 

22 originate. 

23 2. A subject box for the mail 

24 3, A list of the e-mail and alias addresses to which messages can be sent for 

25 die user to select one or more. The original version could only send to one 

26 alias. The user can also supply an Interact e-mail address off system. 

27 4. A list of the e-mail and alias addresses to which copies of the messages 

28 can be sent for the user to select one or more. The user may also supply an 

29 Internet e-mail address off system. The original version did not include a 

30 "CC feature. 

31 5. A space where the message can be typed, allowing for users to paste text 

32 copies form another system using the Windows-based clipboard utility. 

31 
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1 6. AcheckboxtosdKtwhether&es^ 

2 to the recipient on mutual consent 

3 7. A check box to select whether the copies of the message should be sent to 

4 other subscribers who share the Alias. The original version allowed only one 

5 subscriber to access an alias. 

6 ffr 1i YT~ "f Messages - After an Amail message has been composed (see step 7), it 

7 is delivered as follows. 

8 1 . The body of the email message is modified by adding a header including 

9 routing information and an indication of whether the sender is willing to reveal 

10 identities if there is reciprocal concurrence. The message would appear as shown 

11 below. The items in italics are new since the original (prior art) version. The first 

12 generation of the anonymous mail system did not allow for communications between 

1 3 multiple Amail systems and, hence, did not list the Amail system name in the list of 

14 respondents. The first generation system also did not allow for multiple recipients. 
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This message was sent anonymously from alias: Amail system name: alias 

The message was sent to: 

Amail system name: alias 

Amail system name: alias (cc) 

Amail system name: alias 

The sender is willing to reveal identities. 

[Original body of the message] 



2 . if the message is sent to a specific, non-anonymous e-mail address, Amail 
composes and transmits a standard Email message. The sender is listed as 
"arnaiLadmin^ias@xxxxx" where "xxxxx" is the address of the standard mail server 
supporting the mail system. Off-system access was not a feature of the first version. 

3. If a message is sent to an alias on the local or any other related Amail 
system, and the owner of the alias has an off system email address, a message is sent 
as in step 1, above. In addition, however, the message is stored in an Amail message 
database for access through the Amail system interface. The original version did not 

16 have an Amail message database. 

4. If a message has been sent to an alias for which there is no associated 
conventional mail account, the message is stored in the Amail message database. The 
Amail message database contains a repository for all messages, listing the 

z u subscribers) associated with the alias to which the message was addressed. The 
21 database contains the message (including sender, addressees, and ccs), date and time 
of transmission, and the alias of the subscriber to which the message was sent The 
original version did not have an Amail message database. 

5. If the option was checked to send copies to other that share the alias (see 
above), copies of the message are placed in the message database for the subscribers 

2 6 associated with each of the aliases. 

2 7 p^ P tnf M^es- Messages sent from the Amail system can be received in a 
standard e-mail client by Amail subscribers and non-subscribers. 

Amail subscribers can also receive messages through an Amail reader 
interfece. All messages received are placed in the Amail message database (see 
above). Since an alias can be associated with more than one subscriber, the Amail 
message database can list more than one subscriber as an -owner- of the message 
even if it was sent to only one alias. When a user logs on and selects the option to 



33 



SUBSTITUTE SHEET (RULE 26) 



_Page37of 115 

DA 2,345,241 ^ 



WO 00/17773 



Cfc 02345241 2001-03-22 

FCT/US99/21934 



read Amail messages (see above) the messages are rendered as an HTML page • 
through a browser. Messages to all of the aliases associated with the user are 
displayed. Each message has a hotlink to respond to send a message back to the 
sending alias. Each message also has a link to display the background and validation 
information and note associated with the alias (see above). The original version did 
not provide an Amail viewer nor did itprovide for display ofvahdaiioninfimnation. 
PfflMt ff *™ off *V«™ fa" Amail- Individuals from off system can respond 
to Amail messages using the standard reply feature of their mail server. Messages 
will be returned to the reply address (see above). Messages received by the 
conventional e-mail server supporting the Amail system will forward the message to 
the Amail message repository for the alias listed in the return address. Responding 
from a standard Email client was not provided in the original version. 

13 Flin Wideet 

14 Increasingly, computer applications are delivered through browsers over the 
Internet or an intranet. There are many design considerations in building a system 
for browser delivery in contrast to delivery as conventional client server appUcation. 
Two related considerations are the graphic richness of a browser screen and the time 
lag to render a new screen. Partly because good web pages contain complex graphics 

19 and partly because the Internet can be a relatively slow network, it is important to 

2 0 design a web application to make few unnecessary wholesale screen changes. It is 

21 more economical from the perspective of data transmission and, hence, from response 

22 time, to create a "flat" rather than "deep" hierarchy of screens, and change only the 

23 part of a screen that is minimally necessary. 

24 For example, it is better in a data query to provide a single screen that allows 

25 a us« to specify a state and city within the state man to provicle a first screen for the 

26 state, followed by a second screen for the city. As the function of screens becomes 

27 more complex, however, it becomes an increasingly difficult challenge to fit all of 

28 the options onto the screen (particularly when a user selects a lower screen 

29 resolution) and while maintaining a clean appearance. The invention described here 

3 0 provides a tool that allows the Internet application developer to display an effectively 

31 uruimited number of options in a very small space using a very familiar and intuitive 

32 display feature. 

33 Armearance - The "Flip Widget" tool renders a graphical object representing two 
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rows offilefolden, overlapping. The labels on the front row are visible, the labels 
on the second row are obscured by the front row of tabs, but the edges of the apparent 
back tabs are visible. The number of the apparent tabs displayed in each row is a 
function of the screen resolution and the length of the longest label entered by the 



The Flio Tab- In one embodiment, the rightmost tab on the front row is labeled 

7 "FLIP". When a user actuates this tab, the response is as described below. 

8 rvtf pt^ of labels and links,- In creating the display, the application programmer 

9 enters a set of paired values. Each pair consists of (1) text of the label to be displayed 

10 and a tab, and (2) the name of an HTML link, either within or external to the page to 

11 be rendered when the tab is selected. 

12 AtfifllL- Upon rendering a page containing the flip widget, the two-row tab display 

13 shows the first "n" options from the list of labels and links. The value of V 

14 represents the maximum number that can be displayed while allowing room for the 

15 flip tab. Upon clicking any of these tabs, the corresponding link is executed. Upon 

16 clicking the flip tab, the two-row tab display is changed to reflect the next *«n" options 

17 from the list of labels and links, retaining the flip tab on the right If there are fewer 

18 than n options remaining, the flip widget will either display last n °P tiom » OT 

19 whatever number remain supplement by as many options are needed from the start 

20 of the list Clicking the flip tab when the list has been completed starts the cycle over 

21 again with the first option. 

22 Referring to FIGS. 9 and 10, a flip widget in a first state is shown in FIG. 9. 

23 La the first state, any of the tabs A through E can be selected and the corresponding 

24 set of controls displayed. For example, in FIG. 9, tab B has been selected and the 

25 controls 430-432 are displayed. If the flip tab 410 is selected, a next row of tabs is 

26 brought forward so that the display appears as in FIG. 10 with tabs F through J 

27 showing. In FIG. 10, tab G has been selected and the corresponding controls 435- 

28 437 are displayed. 

29 FIGs. 9A and 10A show a more detailed example of how a flip widget can be 

30 used to organize functions available to a user. For example, suppose that one 

31 application is a commodity futures trading system that permits a user to execute 

32 trades, review prices, and obtain other information relating to various metals such as 

33 gold, silver, and platinum. As shown in FIG. 9 A, for example, controls or functions 
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2 3,,^ a "gold" eaKfpry cm b. tavok«i «*«y that caKgPOM* « 
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the foreftontofthc flip widget as shown. Clkki^ one ofthc other tabs (.g.. silver 
tab 400) would bring the functions associated with that category to the forefront 
while allowing the user to readily select other categories visible behind the front 
Clicking "other markets" tab 410 would change the selection of front-row tabs to a 
^setofcategorie^asshowninnaiOA. Toother markets- tab 410 could 
be continually clicked to rotate through a plurality of groupings of markets, each 
having a set of functions or controls associated therewith. 

A flip widget can be implemented in conjunction with the first or second 
embodiment, of the present invention in order to permit many different funcfons to 
be displayed in a small screen space. The flip widget is a device to organize many 
different functions in a logical way, and can be used as a tool for building an interface 
to multiple applications. As one example, in a DCE (described in more detail 
bdow). there may erist n functions (e.g. bulletin boards, chat rooms, e-mail, a-mau. 
transaction engines, and the like) the specific availability of which can be defined by 
a user who creates the collaborative environment Tnis collection can change over 
tune. Accordingly, the interface cannot be "hard coded" for a particular user. 

One way to represent an indefinite (and potentially large) number of functions 
m a small space is with tabs resembling a file folder, with a graphic element 
representing hidden cards, implying that the user can reach the functionality on the 
catdsbypaging(i.e.mppmg) to them The flip widget rnakes it possible to provide 
aliritoalistofapphcanon^ 

bc hard coded. Prograrnrnmg logic for storing folder labels in a database, linking 
those labels with associated functions and activating them using browser-type 
buttons, and for performing the display features described above, are conventional 
and no further elaboration is necessary. Although the 'flip widget" provides one 
method of structuring a user interface to structure a user's view of application 
29 functions, other methods can of course be used. 

31 J,, a second embodiment of the invention, a dynamic, user-defined 

32 collaborative environment can be created in accordance with a set of tools and 

33 method steps. As explained previously, this system differs significantly from 
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conventional networked environments in that ( 1) the ermronment (including access 
and features) is user-defined, rather than centrally defined by a system admutiauator, 
(2) each environment can be easily destroyed after completion of its intended 
purpose; (3) users can specify a group of participants entitled to use the environment 
5 and can define services available to those participants, including offering 
participation to unknown potential users; (4) the networked environment (including 
access features and facilities) can cross corporate and other physical boundaries; and 
(5) the environment offers a broad selection of tools that are oriented to 
9 communication, research, analysis, interaction, and deal-making among potential 
group members. Moreover, in a preferred embodiment, the environment is 
implemented using web browser technology, which allows functions to be provided 

12 with a minimum of programming and facilities communication over the Internet. 

13 FIG. 11 shows various metr»d steps that can be canied out to defme, create, 

14 and destroy an enviromnent according to ^ ^ 

15 term "environment" as used herein refers to a group of individuals (or computers, 

16 corporations, or similar entities) and a set of functions available for use by that group 

17 when they are operating within the environment. It is of course possible for one 

18 individual to have access to more than one environment, and for the same functions 

19 to be available to different groups of people in different environments. 

20 The process of creating a collaborative environment involves the migration 

21 of tools and information resources available in the library of the environment 

22 generator into a specific collaborative environment The collaborative 

23 environment can include / link to any application available to the environment 

24 generator. It can also include applications specific to the environment provided 

25 that theses are accessible through Internet protocols. 

2 6 Underlying the environment is a directory of users, information about 

27 users, and their authorities. The core structure for the environment user database 

28 should conform to a directory standard - typically DAP (Directory Access 

29 Protocol) or LDAP (the lightweight directory access protocol). Trie environment 

30 generator has access to its own directory of users and to the user directories of the 

31 environments it has generated. The directory of an erxvironment can be populated 

32 initially by selecting users from the environment generator's directories. These 

33 are added to the directory of the environment in one of two ways depending on the 
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1 specific implementation. Directory records can be copies from the environment 

2 generators user database to a separate database for the environment or a flag can 

3 be added to the user data record in the environment generators users database to 

4 indicate that the user has access to the environment The second, simple model is 

5 useful when all users in an environment have equal authority. A separate user 

6 database (directory) is necessary for an environment when the environment has its 

7 own security / authority model. 

8 Additional members can be added through a set of standard application / 

9 subscription routines. These then become known to the environment generator (as 

10 well as the specific environment) providing the foundation for greater speed and 

1 1 efficiency in creating subsequent environment 

12 Beginning in step 1101, a new group is created by identifying it (i.e., giving 

13 it a name, such as "West High School Research Project," and describing it (e.g., 

14 providing a description of its purpose). The process of creating a group and defining 

1 5 functions to be associated with the group can be performed by a user having access 

16 to the system without the need for system administrator or other similar special 

17 privileges (e.g., file protection privileges, adding/deleting application program 

18 privileges, etc.). In this respect, environments are, according to preferred 

1 9 embodiments, completely user-defined according to an easy-to-use set of browser- 

20 driven user input screens. The principles described herein are thus quite different 

2 1 from conventional systems in which a central system administrator in a local area 

22 network can define "groups" of e-mail participants, and can install application 

23 programs such as spreadsheets, word processing packages, and the like on each 

24 computer connected to the network. Moreover, according to various preferred 

2 5 embodiments, the facilities provided to group members can be provided through a 

26 web-based interface, thus avoiding the need to install software packages on a user's 

27 computer. 

28 It is also contemplated that various methods of obtaining payment for creating 

29 or joining groups can be provided. For example, when a new environment or group 

30 is created, the person or entity creating the group can be charged a fixed fee with 

31 payment made by credit card or other means. Alternatively, a service fee can be 

32 imposed based on the number of members that join, the specific functions made 

3 3 available to the group, or a combination of these. Moreover, fees could be charged 
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1 to members that join the group. The amount of the fee could also be based on the 

2 length of time that the environment exists or is used 

3 Although not specifically shown in FIG. 1 1, step 1 101 can include the step 

4 of creating a new entry in a database table (e.g., a relational or object-oriented 

5 database) to store information concerning the new group and the environment in 

6 which the group will operate. Database entries related to the group, including some 

7 or all of the information described below, can be created as the environment is 

8 defined. It is assumed that one or more computers are linked over a network as 

9 describ ed in more detail below in order to permit be environment to be created, used, 

10 and destroyed, and that a database exists on one or more ofthese computers to store 

1 1 information concerning the environment 

12 In step 1102, the group members are identified According to various 

13 embodiments, the group members can be identified in three different ways (or 

14 combinations thereof), as indicated by sub-steps 1 102a, 1 102b, and 1 102c in FIG. 11. 

15 It is contemplated that group members can span physical networks and computer 

16 systems, such as the Internet Consequently, group members can include employees 

17 of different corporations, government agencies, and the like. In contrast to 

18 conventional virtual private networks, both the group members and the functions 

1 9 made available to those group members are entirely user-selected, thus permitting a 
2 0 broad range of persons to easi ly create, use, and destroy virtual private networks and 

2 1 associated functionality. 

22 First, in step 1102a, group members can be identified by selecting them from 

23 a list of known users that are to be included in the group. For example, within a 

24 corporation or similar entity, a list of internal e-mail addresses can be provided, or 

25 an electronic version of a phone list or other employee list can be provided If the 
2 6 hosting computer system is associated with a school, then a list of students having 

2 7 accounts on die computer (or those in other schools that are known or connected to 

28 the host) can be provided. From outside a corporate entity, users can be selected 

29 based on their e-mail addresses (e.g., by specifying e-mail addresses that are 

3 0 accessible ova* the Internet or a private or virtually private network), In this step, die 
3 1 environment creator specifies or compels group members to belong to the group. 

3 2 Second, in step 1 1 02b, group members can be invited to join the group by 

33 composing an invitation that accomplishes that purpose. For example, a group 
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1 creator may choose to send an invitation via e-mail to all members of the corporation, . 

2 or all members of a particular department within the corporation, all students in a 

3 school or region, or members of a previously defined group (e.g M the accounting 

4 department, or all students in a particular teacher's class)* The invitation would 

5 typically identify the purpose of the group and provide a button, hyperlink, or other 

6 facility that allows those receiving the invitation to accept or decline participation in 

7 die group. As those invited to join the group accept participation, their responses can 

8 be stored in a database to add to those members already in die group. Invitations 

9 could have an expiration date or time after which they would no longer be accepted 

10 As invitees join the group, the group creator can be automatically notified via e-mail 

1 1 of their participation, 

12 Third, in step 1102c, group members can be solicited by way of an 

13 advertisement that is sent via e-mail, banner advertisement on a web site, or die like. 

1 4 Persons that see the advertisement can elide on it to join the group. It is also possible 

1 5 for advertisements to have a time limit, such that after a predetermined time period 

16 no more responses will be accepted. The primary difference between advertising 

1 7 participation in a group and inviting participation in a group is that invitations are 

18 sent to known entities or groups, while advertisements are displayed to potentially 

19 unknown persons or groups. 

20 It will be appreciated that group members can be selected using combinations 

21 of steps 1102a, 1102b, and 1102c. For example, some group members can be 

22 directly selected from a list, while others are solicited by way of invitation to 

23 specifically identified invitees, and yet others are solicited by way of an 
2 4 advertisement made available to unknown entities. 

25 In step 1 103, the functions to be mole available to the group are selected. For 

2 6 example, the group can be provided with access to an auction transaction engine; a 

2 7 survey tool; research tools; newswires or news reports; publication tools; blackboard 

28 facilities; videoconferencing facilities; and bid-and-proposal packages. Further 

2 9 details of these facilities and tools are provided herein. The group creator selects 

3 0 from among these functions, preferably by way of an easy-to-use web browser 

3 1 interface, and these choices are stored in a database and associated with the group 

32 members. Additionally, the group creator can specify links to other web-based or 
3 3 network-based applications that are not included in the list by specifying a web site 
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1 address, executable file location, or the like The group creator can also define shared 

2 data libraries that will be accessible to group members. 

3 In step 1104, the environment is created (which can include the step of 

4 generating a web page corresponding to the group and providing user interface 
selection facilities such as buttons, pull-down menus or the like) to permit group 

6 members to activate the functions selected for die group. In some embodiments, 

7 access to the group may require authentication, such as a user identifier and password 

8 that acts as a gateway to a web page on which the environment is provided Other 

5 techniques for ensuring feat only group members access the group Amotions and 

10 shared information can also be provided A web page can be hosted on a centre! 

1 1 computer at an address that is then broadcast to all members of the group, allowing 

12 them to easily find the environment 

13 In step 1105, group members collaborate and communicate with one another 

14 using the facilities and resources (e.g, shared data) available to group members. In 

15 the example provided above, for example, a group of high school students 

16 collaborating on a school research project could advertise for survey participants; 

1 7 conduct an on-line survey; compile the results; communicate the results among the 

18 group members; brainstorm about the results using various brainstorming tools; 

1 9 conduct a videoconference including group members at various physical locations; 

20 compile a report summarizing the results and exchange drafts of the report; and 

2 1 publish the report on a web site, where it could optionally be offered for sale through 

22 the use of an on-line catalog transaction engine. The group could even contact a 
2 3 book publisher and negotiate a contract to publish the report in book form using bid 

24 and proposal tools as described herein. 

25 Instep 1106, after the environment is no longer needed, it can be destroyed 

26 by the person or entity that created the group. Again, in contrast to conventional 

2 7 systems, die destruction of the environment is preferably controlled entirely by the 
user that created the environment, not a system administrator or other person that has 
special system privileges. Destruction of the environment would typically entail 

3 0 deleting group entries from the database so that they are no longer accessible. 

3 1 FIG. 12 shows one possible system architecture for implementing the steps 

32 described above. As shown in FIG. 12, an Internet Protocol-accessible web server 

33 1201 is coupled through a firewall 1202 to the Internet 1203. The web server includes 
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1 an environment generator 1201a which can comprise a computer program that 

2 generates user-defined environments as described above. Further details of this 

3 computer program are provided herein with reference to FIG. 21 . 

4 Web server 1201 can include an associated system administrator terminal 

5 1204, one or more CD-ROM archives 1205 for retaining permanent copies of files; 
€ disk drives 1206 for storing files; a database server 1207 for storing relational or 

7 object-oriented databases, including databases that define a plurality of user- 

8 controlled environments; a mail server 1208; and one or more application servers 

9 1209 that can host application programs that implement the tools in each 

10 environment Web server 1201 can also be coupled to an intranet 1210 using IP- 

11 compatible interfaces. Intranet 1210 can in turn be coupled to other application 

12 servers 121 1 and one or more user computers 1212 from which users can create, 

13 participate in, and destroy environments as described herein, preferably using 

14 standard web browsers and IP interfaces. Web server 1201 can also be coupled to 

15 other user computers 1217 through the Internet 1203; to additional appUcation 

16 servers 1215 through another firewall 1216; and to another IP-accessible web server 

17 1213 through a firewall 1214. 

18 It will be appreciated that the system architecture shown in FIG, 12 is only 

19 one possible approach for providing a physically networked system in which user- 
2 0 defined network environments can be created and destroyed in accordance with the 

2 1 principles of the present invention. It is contemplated that application programs that 

22 provide tools used in a particular user-defined environment can be located on web 

23 server 1201, on user computers 1217, on application servers 1215, on application 

24 servers 1209, on application servers 121 1, or on any other computer that provides 

25 communication facilities for communicating with web server 1201. It will also be 
2 6 appreciated that web pages that provide access to each user-defined environment 
27 need not physically reside on web server 1201, but could instead be hosted on any 

2 8 of various computers shown in FIG. 12, or elsewhere. 

29 Reference will now be made to exemplary steps and user interfaces that can 

30 be used to carry out various principles of the invention, including steps of creating 

31 a group, selecting group members, and defining functions to be made available to 

3 2 group members in the environment 

33 FIGS. 13A through 13C show one possible user interface for creating a group 
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1 and identifying group members. In FIG. 13 A, a user gains access to an environment 

2 creation tool by way of an authentication process. This may be a simple usemame 

3 and password device as shown in FIG. 13 A, or it could be some other mechanism 

4 intended to verify that the user has access to the environment creation tool. In the 

5 case of a corporation, school, or other entity that already provides a log-in procedure 
€ to access the entity's network, such log-in procedure could serve to authenticate the 

7 user for the purpose of creating a new environment It should be appreciated that 

8 user authentication is not essential to carrying out the inventive principles. 

9 Moreover, although it is contemplated that for ease of use (and to minimize 

10 programming) web browsers and web pages be used to receive user-defined 

11 information to create each environment, other approaches are of course possible. 

12 In FIG. 13B, the user is prompted to create a new group by supplying a group 

13 name (e.g., "Joe's Homework") and a brief description of the group. This 

14 information is preferably stored in a database file and associated with group members 

15 and functions available to those group members. 

16 hi FIG. 13C, the user is prompted to identify group members. As described 

17 previously, group members are preferably identified in one of three ways (or 

18 combinations of these); (1) selection from a list of known group members; (2) 

1 9 inviting known candidates to join the group; or (3) advertising for new members. 

20 When the user clicks one of the options in FIG. 13C, he or she is prompted to supply 

2 1 additional information as shown in FIGS. 14A through 14C. 

22 Beginning with FIG. 14 A, for example, group members can be individually 

23 specified by entering an e-mail address (e.g.. an internal or external e-mail address) 

24 in a text form data entry region and/or by selecting from a previously known list. 

25 This screen permits the user to compel attendance in the group by specifying names 

26 and/or e-mail addresses to which group messages will be sent. All those added to the 

27 group in this manner will be provided with access to the environment conesponding 

28 to the group. Aliases and pre-defined groups could also be specified as the basis for 

2 9 membership (eg., all those in the accounting department of a corporation, or all 

3 0 students in a high school). 

31 Each member of a group might have a group email account, or they may use 

32 an off-system email account. Off-system email addresses can be maintained in a 

33 database of users. Mail sent to the group email address is preferably forwarded off- 
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1 system, protecting the actual email address of the person unless that person wishes 

2 to give out thai address. New members can be added until the group is completed 

3 Although not explicitly shown in FIG. 14 A, it is contemplated that new members 

4 can be added to a previously defined group after the environment has already been 

5 created. 

6 When group members are selected or specified, the user creating the 

7 environment can also create a password for each user in the group in order to enable 

8 those in the group to access the environment. Alternatively, when a user visits die 

9 environment, the environment can retrieve a "cookie" from the user's computer to 

10 determine whether the user is authorized to access the environment If no cookie is 

11 available, the user could be prompted to supply certain authentication information 

12 (e.g., the company for whom he or she works, etc.) In yet another approach, 

1 3 authentication could occur by way of e-mail address (i.e., when the user first visits 

14 the environment, he or she is prompted to enter an e-mail address). If the e-mail 

15 address does not match one of those selected for the group, access to the environment 

16 would be denied. 

1 7 Turning to FIG. 14B, prospective group members can also be "invited" to join 

18 the group. The user creating the environment can specify one or more e-mail 

19 addresses to which an invitation will be sent The invitation can be a simple text 

20 message, or it could be a more sophisticated video or audio message. An expiration 

2 1 date can also be associated with the invitation, such that responses to the invitation 

22 received after the date will not be accepted Software resident in web server 1201 
2 3 (FIG. 12) receives responses to the invitations and adds members to the appropriate 

24 group or drops them if die expiration date has passed or the prospective group 

25 member declines participation. Prospective members can join the group by sending 

26 a reply with a certain word in the message (e.g., "OK" or 'I join"); by clicking on a 

2 7 button in an e-mail message; or by visiting a web site identified in the invitation. 

28 Turning to FIG. 14C, group members can also be solicited by creating an 

29 advertisement directed primarily at potential group members that are unknown The 

3 0 advertisement could include, for example, a banner ad comprising text, video, and/or 

31 audio clips. The graphic should conform to the size designated for the ad on the web 

32 page. The ad could be posted on a web site by uploading the graphic through a web 

33 interface and, optionally providing a URL on the screen of FIG. 14C to link to if the 
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1 advertisement is clicked Software on the group page can render advertisements on . 

2 a page either (a) eveiy time the page is displayed, (b) in rotation with other ads; or 

3 (c) when characteristics of the user match criteria specified for the ad. 

4 The advertisement can include an expiration date after which responses would 

5 no longer be accepted. Advertisements could range from the very specific (e.g., an 

6 advertisement posted on a school's home page advertising participation in Joe's 

7 research project on drug use at the school) to more general (e.g., an advertisement 
3 that says "we're looking for minority contractors looking to establish a long-term 
9 relationship with us" that is posted on web sites that cater to the construction 

10 industry. 

11 A qualification option can also be provided to screen prospective group 

12 members. For example, if an advertisement seeks minority contractors to participate 

13 on a particular construction project, selecting the "qualify" option would screen 

14 responses by routing them to the user that created die group (or some other authority) 

15 before the member is added to the group. Those responding to the advertisement 

16 could be notified dial they did not pass the qualifications for membership in the 

17 group, or that further information is required (e.g., documents evidencing 

1 8 qualifications) before participation in the group will be permitted. Alternatively, an 

1 9 automatic qualification process can be provided to allow a prospective member to 

20 join if the person fills in certain information on the response (e.g., e-mail address, 

2 1 birthdate that meets certain criteria, or the like). 

22 As shown in FIG. IS, a banner ad displayed on a web site invites minority 

23 contractors to join a group that bids on information technology contracts. Those 
2 4 interested in the advertisement click a button, which leads them to another site (not 

25 shown) requiring that they provide certain information (qualification information, 

26 name, age, company registration information, etc.) This information is then 
2 7 forwarded to web server 1201 which either pre-screens the information according to 

28 pre-established criteria, or notifies the user creating the group that a prospective 

29 member has requested access to the group. In the latter case, the user could screen 

30 the applicant and grant access to the group. 

3 1 FIG* 16 shows one possible user interface for selecting communication tools 

32 to be made available to group members. This screen can be presented to the user 

33 creating the environment after the group has been identified and its members 
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1 selected. It is contemplated that a variety of communication tools can be provided, 

2 including a bulletin board service; advertisements; white pages (e.g., a listing of 

3 members, their e-mail addresses, telephone numbers, and the like); yellow pages 

4 (eg., a listing of services or companies represented by group members, with 

5 promotional and contact information); document security (e.g., shared access secure. 

6 document storage services); anonymous e-mail (described above with respect to the 

7 first embodiment); threaded dialogs; a group newsletter creation tool; 

8 videoconferencing; and even other user-provided applications that can be specified 

9 by name and location (e.g., URL). Details of these services are provided below. 

10 According to various preferred embodiments, dynamic collaborative 

1 1 environments are designed to integrate tools from multiple sources provided that they 

12 are web-accessible (i.e., they operate according to Internet Protocol and/or HTML- 

13 type standards). The categories listed above provide a reasonable taxonomy of the 

14 tools necessary for collaboration, but this list can be extended to include virtually 

15 every class of software such as computer-assisted design, engineering and financial 

16 analysis tools and models, office applications (such as word processing and 

1 7 spreadsheets), access to public or proprietary databases, multimedia processing and 

1 8 editing tools, and geographic information systems. The following describes some 

19 of die communication tools that can be provided: 

2 0 Bulletin boards. A bulletin board (see, e.g., FIG. 2) lists notices posted by 

2 1 group members, which may be offers to buy or sell, but need not be limited to such 

22 offers. Many types of bulletin board services are of course conventional and no 

23 further discussion is necessary in order to implement one of these services. 

24 Nevertheless, in one embodiment the following data items (attributes) can be 
2 5 provided for each notice appearing on the bulletin board: an item number, a title, the 

26 date posted, and one or more special attributes defined by the user. The attributes 

27 may include a field to indict whether a li^ The board 

28 can be provided with an integrated sorting capability. By clicking on the heading 

2 9 of each column, the user can sort the entries in, alternately, ascending or descending 

3 0 order. Thus, it is possible to organize the records from oldest to newest or newest to 

3 1 oldest, or to separate buy and sell offers. To limit the values on a board, a search 

32 capability can also be provided, such that only those entries that meet the search 
3 3 criteria are displayed. 
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1 Advertisements. In a typical environment of a dynamically created network 

2 there are a number of fixed p laces for advertisements - the top of a page for a banner, 

3 the bottom of a page for a banner, and space on the side for small ads. The creator 

4 of the environment may choose to use none, any, or all of these spaces for 

5 advertisements* Once a space is designated for advertising, group members may 

6 place adds by completing a template that provides payment information (if required), 

7 the text for the ad (any standard image format), and a link to be executed if the ad is 

8 clicked by someone viewing the ad. 

9 Each user is responsible for providing functionality behind the link- The ad 

10 may be displayed persistently (every time a page is displayed), in rotation with other 

11 ads for die same place, or may be triggered on the basis of user characteristics 

12 including purchasing history. Revenue can be collected for placement (fixed price 

1 3 regardless of how many times an ad is displayed), per time that the ad is displayed, 

14 or per click on the ad. The virtual private network provides the front-end to facilitate 

15 online placement of the ad. Display can be done by linking pages to standard ad 

16 display code, available off the shelf from several sources. This code provides for 

1 7 rotation of the ads. Software for customization (ie. choosing the ad based on user 

18 characteristics) is available commercially from several sources. 



19 Whi^c pages. White pages provide a comprehensive listing or directory of 

20 members with information about them and information regarding how to contact 

21 them. Various types of commercially available software can be used to manage such 

22 directories, and it is elementary to code typical directories that have fixed contents 

23 for each member. 

24 A web-accessible directory can be used in accordance with various 

25 embodiments of the invention. One type of directory that can be provided differs 

26 from directories having fixed structures. The key differences are as follows: 

27 (a) User control over information Users enter and maintain their own 

28 information directly, rather than through a central organization. This provides more 
2 9 immediate update of data and reduces transcription errors. It makes it simple, for 

30 example, for people to change their phone number when they are temporarily 

31 working at another location. 

32 Art Multiple points for oualitv control. The data regarding each user can be 

33 displayed to the user periodically (e.g30, 60, and 90 days), and the user prompted to 
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1 update and verify the data. A feedback capability can be provided for members of . 

2 a group to report errors they find. Email addresses can be "pinged" periodically to 

3 determine if they still exist In addition^ server management staff can periodically 

4 review accounts that have had recent activity. 

5 (c) Qfrjest gttM3B& A directory entry consists of a collection of data 

6 elements. These elements include such things as name for addressing (Dr. John D. 

7 Smith), sort name (Smith, John D), or primary work telephone (800-555-1212). 

8 Traditional mail systems have a fixed number of rigidly formatted elements. In one 

9 embodiment, a more flexible approach can be used in that individuals identify which 

1 0 elements they wish to add to the collection comprising their directory entry. For 

1 1 example, a person can add 3, 4, 5 or more telephone numbers attaching a note to each 

12 explaining its use (e.g. "for emergencies after 8PM"). 

13 (d) Pirect link to communications took. Where a directory refers to a contact 

14 method (e.g, a telephone number), the method can be invoked directly from an entry 

15 if the necessary software is available. For example, phone number can be dialed, 

16 email messages initiated, or a word processing session initiated with letter and 

1 7 envelope templates, preloaded with address information. 

18 ( e ) Descriptive information In addition to contact information, each directory 

19 can contain information describing the entry (individual or business). The 

20 description can be different in each group or it can be the same. The descriptive is 

21 free form, with the exception that the user may drop in terms from a group-specific 

22 lexicon. This lexicon can include terms specific to the industry (e.g. "fuel system") 
2 3 for the automotive industry, or preferred forms of standard terms (e.g. "California" 
24 rather than "CA", "Ca", or "Calif"). Standardization of terms in this way makes 
2 5 search the directory more reliable. 

26 Yellow pages. Conventional "yellow pages" products provide a one level 

27 classification of directory entries designed to facilitate identification of and access 

28 to an individual or organization with specific interests and capabilities. Within 

29 industries, and particularly online, multi-level hierarchical directories are common, 

30 with the multiple levels providing more precise classification. There are numerous 

31 commercial products for maintainmg online yeUow page tvpeclaCT 

32 Any web-accessible directory can be connected to a DVPN group. A 

33 preferred method offered with the system integrates the classification system with the 
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1 update and verify the data. A feedback capability can be provided for members of . 

2 a group to report errors they find. Email addresses can be "pinged" periodically to 

3 determine if they still exist In addition, server management staff can periodically 

4 review accounts that have had recent activity. 

5 (c) Object structure. A directory entry consists of a collection of data 

6 elements. These elements include such things as name for addressing (Dr. John D. 



7 Smith), sort name (Smith, John D), or primary work telephone (800-555-1212). 

8 Traditional mail systems have a fixed number of rigidly formatted elements. In one 

9 embodiment, a more flexible approach can be used in that individuals identify which 

1 0 elements they wish to add to die collection comprising their directory entry. For 

1 1 example, a person can add 3 1 4, 5 or more tel ephone numbers attaching a note to each 

12 explaining its use (e.g. "for emergencies after 8PM"). 

13 (dS Direct link to communications tools. Where a directory refers to a contact 

1 4 method (e.g. a telephone number), the method can be invoked directly from an entry 

15 if the necessary software is available, For example, phone number can be dialed, 

16 email messages initiated, or a word processing session initiated with letter and 

1 7 envelope templates, preloaded with address information. 

18 M Descriptive information. In addition to contact mfomrmttm^ **rh dimrtmy 

19 can contain information describing the entry (individual or business). The 
2 0 description can be different in each group or it can be the same. The descriptive is 

21 free form, with the exception that the user may drop in terms from a group-specific 

22 lexicon. This lexicon can include terms specific to the industry (e.g. "fuel system") 
2 3 for the automotive industry, or preferred forms of standard terms (e.g. "California* 9 
24 rather than 4< CA*\ "Ca'\ or "Cali£"). Standardization of terms in this way makes 
2 5 search die directory more reliable. 

2 6 Yellow pages. Conventional "yellow pages'* products provide a one level 

2 7 classification of directory entries designed to facilitate identification of and access 

28 to an individual or organization with specific interests and capabilities. Within 

2 9 industries* and particularly online, multi-level hierarchical directories are common, 

3 0 with the multiple levels providing more precise classification. There are numerous 

3 1 commercial products for maintaining online yellow page type classification systems. 

32 Any web-accessible directory can be connected to a DVPN group. A 
3 3 preferred method offered with die system integrates the classification system with the 
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1 descriptive field in a directory entry. Every time a standard term pertaining to a . 

2 classification is pulled from the lexicon, the entry is added to that classification in the 

3 hierarchical soil In addition to hierarchical access, this correspondence between die 

4 traditional hierarchical sort and the free-form description with standardized terms 

5 makes h possible to access records via search rather than browsing the hierarchy. 

6 Searching makes it possible to identify an organization with multiple capabilities 

7 (e.g, "brake repair" and "frame straightening")' This search capability is much like 

8 a general web-search using a tool like AltaVista's or Inktomi's search engine and can 

9 use the same search engine, but differs in that material being search is in a precisely 

10 defined domain (group members), the information being searched is limited and 

1 1 highly quality controlled (i.e. group directory entries), and has a precision rooted in 

12 a precise vocabulary (the lexicon used in preparing the description). 

13 DffgMt ITOfflWirY* Any commercial web-enabled document repository 

14 can be integrated into a group. Examples are Documentum and PC DOCs. An 

1 5 improved version offered specifically with the DVPN package was described above. 

16 Document security. Within the document repository various tools can be 

17 provided to protect the security of documents. These include (1) limiting access to 

18 a document to certain people or groups; (2) only displaying the directory entry for 

1 9 documents to people who can access it; (3) password protection; (4) encryption; (5) 

2 0 secure archive in read only mode on a third-party machine; (6) time-limited access 

21 and (7) a secure hash calculation. 

22 All of the above are conventional except for time-limited access and the 

23 secure hash calculation, Software for limiting access to a document to a certain 

24 period is available from Intertrust, among others. A secure hash is a number that is 

25 characteristic of the document calculated according to a precisely defined 

26 mathematical algorithm. There are several secure hash algorithms, and implemented 

27 can develop their won. They are "trap door" in nature. That is, the calculation can 

28 be performed with reasonable effort, but the inverse of the function is 

29 computationally intractable. The classic example of a trap door function is 

3 a multiplication of very large prime number (on the scale of hundreds of digits). The 

3 1 product can be calculated with relative ease, but factoring the product (the inverse 

32 function) is very time consuming, making if effectively impossible with generally 

33 available hardware. This method is used in public key encryption, but can be applied 
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1 equally well in secure hash, though other trap door Anions are preferred in 

2 particular, the one specified by the US. Department of Commerce as HPS standard 

3 180 Code to implement this standard can be developed from published algorithms. 
Ap w™™ «-mail (described above with respect to the first embodiment); 

dialogs. Threaded dialogs are a collection of messages addressing 
a specific topic, adced serially. -tm real time. They are threaded in the sense that 
new topics can branch off from a single topic, and topics can merge. According to 
one embodiment, threaded dialogs chffer from conventional news group functionality 
in that (1) users can initiate new topics; (2) users can post a message to one tome, 
then indicate that the message pertains to other topic as well; (3) browsers reading a 
message may «mthrue down the original thread or one of the alternates if other toptcs 

12 are suggested- 

13 ^^i^^onibol. A newsletter creation tool can be used to link 

14 columns provided by multiple users (and maintained as separate web documents) into 
.fhblh^-i^^'^^"^ Thepurposeof 
the tool is to provide the look and feel of an attractive single document to a disparate 
collection. To create the newsletter the editor generates an outline identifying an 
author for each component and a layout. Art for U»e first page can be provided. 
Through messaging, the authors are provided a link to upload their content. Content 
is templated to include a tide, date, a by line, one or more graphic elements, a 
summary for the index, and text. The editor may allow documents to go directly to 

22 "publication" or require impose a review and editing step. 

23 grout* . Real time chat room software is widely available from many 

24 sources including freeware and shareware. 

25 ^^ yf^fereneing . Commercially available tools for web-based 

26 audio and video conferencing can be included in the group functionality. Examples 

27 are Net Meeting and Picture Tel software. 

28 nG. 17 shows one possible user interface for selecting research tools to be 

29 rnade available to group members. As shown in FIG. 17, various tools such as a 

30 mortgage calculator, LEMS/NEXIS access, news services, Valueline. and other 

31 researchtools<^beprovidedbyc^^ 

32 of these research tools are conventional and commercially available (via web-based 

33 links and the like). 
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1 FIG. 18 shows one possible user interface for selecting transaction engines 

2 to be made available to group members. As shown in FIG. 1 8, many different types 

3 of transaction engines can be provided to group members, including electronic data 

4 interchange (EDI) ordering; online catalog ordering; various types of auctions; sealed 

5 bids; bid and proposal tools; two-party negotiated contracts; brain writing (moderated 

6 online discussion) and online Delphi (collaborative estimation of a numerical 

7 parameter). The following describes various types of transaction engines in more 

8 detail. Enhanced features (i.e„ those that differ from conventional products) are 

9 highlighted in gray text 

10 A. Order placement fonline catalog^ transaction engine 

Xi An order placement or online catalog engine allows the buyer to place an 

12 order for a quantity of items at a stated fixed price, essentially ordering from an 

13 online catalog. The catalog contains the description and specification of the 

14 offerings. The catalog may be publicly accessible (Subtype la) or provided for a 

15 specific customer (Subtype lb). Prices are included in the catalog but may be 

16 customer specific, may vary with quantity purchased, terms of delivery and 

17 performance (e.g. cheaper if not required immediately). The catalog can represent 

18 a single company's offering or an aggregate of the offerings from several companies. 

19 The catalog can range from a sales-oriented web site designed for viewing by 

20 customers, to a engine designed only accept orders sent via electronic data 

21 interchange (EDI). Note that the catalog can be shopper oriented (Le. designed to 

22 sell) or a simple, machine-readable list of available items and prices. The following 

23 describes in more detail steps that can be executed to create an online catalog: 

24 1. Enter and maintain a framework for catalog 

25 1.1. Enter / delete / edit categories. Categories are titles for groups of items, such 

26 as "fiuniture" or "solvents" 

27 12. Biter / delete / edit subcategories. Subcategories are categories within 
26 categories, effectively establishing a hierarchy of products. Example: 
2 9 fumiture/dining room/tables. 

30 1.3. Create groups of categories and subcategories (e.g. "see also... The 

3 1 grouping allows a person browsing items to be referred to another category 

32 that may contains items of interest. For example, someone may reach the 

33 ftiraiture/dining room/tables and then be referred to 
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15 
16 



ftnniture/office/conference room tables where other suitable tables may be 
listed, or to fiuniture/dhiing room/chairs to buy chairs that make the table. 
This cross-referencing transforms the hierarchical arrangement of 

4 categories into a web. 

5 2. Enter /edit/ delete items in catalog by entering and updatiiig the information 

6 listed below. The system allows users to enter this information and provides 

7 basic quality assurance. 

8 2.1. Catalog item number 

9 2.2. Supplier part numbers) 

10 2.3. Name of item 

11 2.4. Description 

12 2.5. Photos and drawings 

13 2.6. Specifications (depends on item type). Different items have different 

14 specifications. For example, a computer printer can have color vs. black 
and white, dots per inch resolution, paper size, etc. In contrast to a fixed, 
hard coded catalog, the specification section of the general purpose 

17 catalog engine the user prepares the specification section by selecting 

18 parameters from a list and then specifying a value for that parameter. 
ig The parameter list contains values such as length, width, height, voltage, 

color, resolution etc. It is can be extended by the manager of the auction 
environment. A lister selects a necessary parameter (e.g. length, then 
enter the value, such as 14"). The specification section is a concatenation 

23 of individual specifications. 

24 2.7. First available date 

25 2.8. Last available date 

26 2.9. Category (categories) into which the item fits 

27 2. 10. Alternate suggestion^) if product not available 

28 2.11. Related and associated products (eg. printer supplies for a printer or other 
2 9 household items with the same pattern. 

30 2. 12. Additional information at the option of the individual or organization 

31 listing the item, 

32 3. Enter / update pricing information 

33 3.1. Simple price. The fixed prices is per item or per unit The price must 

52 



20 
21 
22 



SUBSTITUTE SHEET (RULE 28) 



CA. 02345241 2001-03-22 



PCT/US99/31934 

WO 00/17775 

1 specify the 

2 32. Pricing algorithm - link to code for pricing algorithm 

3 4. TakeOidere 

4 Ttec are two variants: 4a; mamial purchase mwWch 

5 and selects and item for purchase and 4b: automated order in which a purchase 

6 is initiated by an electronic message. 

7 Vto"* Aa: Manual Purchase. 

8 4.1. Potential buyers access the catalog by drilling down through the category 

9 /subcategory tree or 

10 4.2. Buyers search fields in catalog to identify the appropriate item. The search 

1 1 may examine the title, description, or any of the specification fields. 

12 A3. Display general information for hem(s) meetings specifications 

1 3 4.4. Allow user to modify search or to select specific item if the items displayed 

14 to do not meet his requirements 

15 4.5. Display detailed information for selected item 

16 4.6. Display the fixed price or calculate price if imces is based on an algorithm. 

17 The pricing algorithm may include parameter such as characteristics or 

18 affiliation of the users (e.g. affiliated with a pre-negotiated discount 

1 9 program) , delivery date and mode, and quantity. 

2 o 4.7. Offerthe option to purchase or search again if they choose not to purchase. 

2 1 4.8. If the buyer opts to proceed with the purchase, then check the availability of 

22 the item by linking to the sellers inventory system 

23 4.8.1. If the item is available then execute an 'add to basket'. That is, place 

24 it on a list of items designated for purchase. 

25 4.8.2. If the item is not available, men execute the coivtiiigent response: 

26 4.8.2.1. Offer delivery at predicted date 

27 4.82.2. Terminate the sale, but offer to deliver or notify when next the 

28 item is next available. 

29 4.82.3. Suggest alternate items 

3 0 4.82.4. Report 'sorry* and abort transaction 

3 1 4.9. Offer option to purchase addition options 

32 4.9.1. If offer is accepted, execute from step 4.1 

33 4.9.2. If offer is not accepted, proceed with step 4.10 
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1 4.10. Conclude the transaction 

2 4.10.1. Collect shipping information, offer options 

3 4. 10.2. Collect payment information 

4 4.10.3. Validate payment 

5 4.10.4. Summarize order 

g 4.10.5. Obtain final authorization 

7 4.10.6. Generate receipt 

8 Yfri^t Ah: autorn ^ "der_ done usiim an FBI (electronic <tt» inteithaqg d 

9 message 

10 4.1 Accept requests for item 

11 4.2 Return price and confirmation of availability 

12 Note that users may conduct transactions without employing EDI. It is 

13 possible, however, for members to agree on a transaction EDI format either by 

14 completing a template within the system or selecting a pre-established EDI format 

15 from a library. This library can include formats developed by recognized standards 

16 organizations (e.g. UNEDFACT or ANSI) or formats developed specifically for an 

17 industry or a trading environment Once there is agreement on a format, transactions 

18 can be initiated, concluded, and confirmed through the exchange of appropriate EDI 

19 messages. As many commercial ordering, accounts payable, accounts receivable and 

20 enterprise resource planning systems have an EDI interface the collaborative 

21 environment should have the capability to forward the message to the order 

22 fulfillment system. 

23 p, jhifMOx Aurtiir Tmtwtii™ Fngine 

24 In an English Auction, a single item is offered for sale to many buyers. The 

25 auction can be open or limited to proqualified bidders. The buyers offer bids in turn, 

26 each suwecding all prior bids. The highest bid received at any point in the auction 

27 is visible to all buyers. The identity ofthe highest bidder may or maynot be visible 

28 to traders. Buyers may increase their bids in response to this information. Award 

29 is to the highest bidder at the end of trading. The end of trading is reached when 

30 there are no higher bids during an interval that may be formally defined or 

31 determined by the manager of the auction at the time of execution. 

32 There are two models for the access to the transactions. In the first model, 

33 all buyers and sellers are members ofthe group. In the second model, all sellers are 
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1 members of the group, but buyers can include members and non-members, Ifnon- 

2 members are allowed to buy, the creator the transaction must enter a new URL for 

3 buyers. This is a sub-URL of the main group URL. A registration process may be 

4 established for the buyer URL. 

5 In live auctions (as opposed to online) all traders are connected at the same 
€ time, and the duration of the auction is brief- typically only a few minutes. In online 

7 trading, it is not necessary for all of the bidders to be present (i.e. connected at the 

8 same time). To distinguish between these two options they are designated (a) 

9 concurrent (everyone bidding at the same time) and (b) batch (not everyone 

10 connected simultaneously. The manager of the auction cm set the minimum bid 

11 and the minimum increment. 

12 1. The first step in conducting an auction is to collect information on the items being 

13 offered for sale. This is done online. The information collected includes: 

14 LI. Identity of seller. Note that the business rules of the auction may require 

1 5 advance registration of sellers to verify their identity. 

16 12. Descriptions, optionally including attachments and photographs, independent 

17 certifications or appraisals, and anything else in digital form necessary or 

1 8 useful in determining the value of the item. 

19 1-3* Reserve price 

20 1.4. Minimum increment 

21 L5. Time offered for sale 

22 1,6. Time bidding is scheduled to end 

23 LX Verify the seller's consent to the rules of the auction house regarding 

24 delivery, payment, responsibility for non payment, etc. 

25 2. If the business rule of the auction house is to require payment up front, collect 

26 payment either by: 

27 2.1. Debiting a deposit account 

2 8 2.2. Charging to account for billing 

2 9 2.3. Collecting online payment such as through a credit card. 

0 3, Post information about auction, including: 

1 3.1. Description of items to be auction 

2 3 .2. Auctions rules: 

3 32.1. Qualification process forbidden 
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1 3.2.2. Time of bidding 

2 3.2.3. Criterion for ending bidding - time between bids 

3 3*2.4. Legal statement - responsibilities of buyer and seller, limitation of 

4 liability 

5 4. Execute qualification process (optional) 

6 4.1, Admit bidders who are qualified based on past participation 

7 42, Provide fill-in-the blank qualification form new bidders 

8 43. Collect information 

9 4 A Conduct automated review or manual review 

1 0 4.5. Inform prospective bidder of qualification or not 

11 Variant fa); WM«mt auction 

12 5. Conduct Auction 

13 5.1. Fifteen minutes prior to appointed time for auction, display "Welcome" 

14 screen with space for qualified bidder to enter an alias or handle to be used 

15 in the auction. Screen should have a description of the object. Showtime 

1 6 until auction starts. Auto refresh at 15 second intervals. 

17 52. At appointed time, display the main auction page with the following 

1 8 information: 

19 5.2. 1. Description / picture of item for auction stored in a separate, static 
2 0 frame of the PC so that it does not need to be downloaded each cycle. 

21 5.2.2- Current bid (initially the reserve price) 

22 5.2.3. Suggested next bid (eg. current + 3 * increment) 

23 52 A. Button to accept suggested next bid 

24 5.2.5. Field to enter bid higher than suggested next 

25 5JZ.6. Handle of the highest bidder 

26 5 J. Refresh main auction page at 15 second intervals 
2 7 5.4. Collect bids, either 

28 5.4.1. Notice that the suggested bid was accepted 

29 5.42. Bid higher than accepted bid 

0 5.4.3. If new bid is lower than current highest, disgard 

1 5.4.4. If higher than current highest then 

2 5,4.4.1. Log identity of highest bidder 

3 5.4.4.2. Update highest bid 
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1 5,4,43. Update next suggested bid 

2 6, If nobody accepts the suggested bid, thai 

3 6,1 . Reduce suggested next bid 

4 62. If accepted, resume normal sequence 

5 6.3. If not accepted, reduce suggested next bid 

6 6A If accepted, resume normal sequence 

7 65. If not, begin close 

8 6.6. "Going once . . if response, resume normal sequence, else 

9 6.7. "Going twice . * if response, resume normal sequence, else 

10 6.8. Done. Display closing screen 

11 7. Settle with winning bidder, two models 

12 7, 1. Connect buyer to seller for direct settlement 

13 12. Collect money from buyer, deduct feet, convey amount to seller 

14 Variant fl>); batch (i.g, tmw limited) wton 

15 Conventional on-line batch (time limited) auctions are common. E-bayis 

16 the most prominent example. This process description continues from step 4 of 

17 the English auction description as the startup of the concurrent and batch auctions 

18 are the same. 

19 5. Conduct auction: Until closing time for an item: 

20 5. 1 . On entry to system display the following for the potential buyer. 

21 5. LI. Latest listing 

22 5.1.2. Categories 

23 5.1.3. Search screen 

24 52. On selection of categories: 

25 5.2. 1 . Execute dill down 

26 5.22. Retrieve count of items that meet criteria 

27 5.2.3. If more count is less than 25 (or other small number (n) 

28 consistent with the layout of the screen) retrieve all items that meet 

29 criterion 

30 5.2.4. If count is more than n, retrieve n auctions with nearest 

31 expiration time 

32 5*2.5. Display link list to all items in list, sort order should be 

33 auction with nearest deadline to most distant 
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1 5.2.5.1. Item name 

2 32.5*2. Time till ad of auction 

3 52.5.3. Highest current bid 

4 52.6. On user selection of the item, display same information as above plus 

5 5.2.6.1. Description 

6 5.2.62. Photo (if any) 

7 52.6.3. Attachments (if any) 

8 52.7. If count is more than n, display further drill-down options as 

9 well as item information above 

10 5.3. Accept new bid through the display screen 

11 53.1. Log bids in order, reject if bid is not higher than last high bid by 

12 increment. 

13 5.32. If bid is rejected, tell bidder that their bid is not sufficient 

14 5 J J. Update database recording highest bid, bidder, time of bid 

15 53.4. Display screen to user to confirm that their bid is the highest 

16 6. When the time limit is reached, determine if a new bid has been received in the 

17 last 3 minutes (or other short time period). If so, extent the bidding time by 3 

1 8 minutes (or other short time period) and execute step 5 with a new closing time. 

19 7. When the time limit is reached, including all extensions under step 6, then 

20 7.1. Email message to highest bidder that they won 

21 72. Add transaction to completed deals 

22 73. Update splash and add screens 

2 3 7.4. Settle with winning bidder- two models: 

24 7.4.1. Connect buyer to seller for direct settlement 

25 7.42. Collect money from buyer, deduct fee, convey amount to sella- 

26 C. Dutch Auction Transaction Engine 

27 A Dutch auction, like a standard auction, involves the sale of a single item or 



28 batch with fixed specifications. There is one seller, and many potential buyers. The 

29 seller sets the prices, ideally higher than any buyer's maximum bid price. The 

30 offered price is reduced by a fixed increment at fixed intervals until a buyer accepts 

31 the price. The purchase goes to the first buyer in to accept the price. In the physical 

32 world (as opposed to the online world), Dutch auctions are rarely if ever run 

33 concurrently. In a live trading room, it could be difficult to determine which buyers 
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1 was first to commit to a price when several are willing to pay the same amount. The 

2 Dutch auction is relatively simple to implement in an electronic environment There 

3 are, at present, no online Ducth Auctions of which the inventors are aware. 

4 1. Enter and maintain a framework for catalog 

5 l.l. Enter/ delete / edit categories. Categories are titles for groups of items, such 

6 as "furniture** or "solvents" 

7 1.2. Enter / delete / edit subcategories. Subcategories are categories within 

8 categories, effectively establishing a hierarchy of products. Example: 

9 furniture/dining room/tables. 

10 1.3. Create groups of categories and subcategories (eg. see also,...). The 

1 1 grouping allows a person browsing items to be referred to another category 

12 that may contains items of interest. For example, someone may reach the 

13 furniture/dining room/tables and then be referred to 

14 funiiture/office/conference room tables where other suitable tables may be 

1 5 listed, or to furniture/dining room/chairs to buy chairs that make the table. 

1 $ This cross referencing makes transforms the hierarchical arrangement of 

17 categories into a web. 

18 2. Execute qualification process (optional) 

19 2. 1 . Admit bidders who are qualified based on past participation 

2 o 2.2. Provide fill-in-the blank qualification form new bidders 
2 1 2.3. Collect information 

2 2 2.4, Conduct automated review or manual review 

2 3 2.5. Inform prospective bidder of qualification or not 

24 3. Collect information on items to be auctioned and owners, including 

25 3.1. Identity of seller 

2 6 32. Descriptions, optionally including attachments and photographs, independent 

2 7 certifications or appraisals, or other information necessary to establish the 

28 value of the tiem 

29 3.3. Categorization 

30 3.4. Starting price 

3 1 3.5. Increment, Interval for reduction 

32 3.6. Minimum price 

33 3.7. Obtain consent to rules (possibly as part of registration/qualification process) 
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1 3,8. Collect to conduct auction if item is 

2 3.9. Calculate time to take item off auction by determining the number of steps 

3 (intervals) necessary to reduce price from the starting price to the 

4 minimum 

5 3.10. Record all of the above information in the Dutch auction database 

6 4. Cull expired options 

7 4.1. Search database periodically for items where current time is later than time 

8 to take item off auction (2.9) 

9 4.2. Inform owner that item was not sold 
10 4 3. Delete entry from database 

H 4.4. Prompt for revised terms start of another auction, create new entry if user 

12 takes option 

13 5. men the buyer enters the system display a to 

14 for search criteria, and/or a link to a search page. Allow user to drill down 

15 through categories or enter search parameters. 

16 5-1 . Retrieve count of items that meet criteria 

17 5.2. If more count is less than 25 (or other small number (n) consistent with the 

18 layout of the screen) retrieve all items that meet criterion 

19 5.3. If count is more than n, retrieve n auctions with nearest expiration time 

20 5 A Display link list to all items in list, sort order should be auction with nearest 

21 deadline to most distant 

22 5.4.1. Item name 

23 5.4.2. Time till end of auction 

24 5.4.3. Current price: 

25 5.43.1. Retrieve starting price (SP) and increment (1$) 

2 6 5.4.3.2. Calculate number of intervals since start of auction (INT) 

2 7 S.43.3. Determine price » SP- (INT * $) 

28 5.5. On click, display same information as above plus 

29 5.6. Description 

30 5.7. Photo (if any) 

3 1 5.8. Attachments (if any) 

32 5.9. The display screen should include a button that allows the buyer to purchase 

33 the item at the selected price. 
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1 6. When the user chcks the *1>uy" button 

2 6. 1 . Email message to highest bidder that they won 

3 6.2, Add transaction to completed deals database 

4 6.3. Settle with winning bidder- two models: 

5 6.3.1. Connect buyer to seller for direct settlement 

6 6.32. Collect money from buyer, deduct fee if any for auction and 

7 payment services, convey the remainder to seller. 

8 n. Reverse English Auction Transaction Engine 

9 In a reverse auction, there are multiple buyers to one seller. Prices come 

10 down rather than up. There are many variants of a reverse auction. The variant 

11 discussed here is a reverse English auction. Reverse auctions have been 

1 2 implemented on line in Open Markets. 

13 The process for posting an item for bid and for qualifying bidders is the 

14 same as for other auctions. The difference here is that the buyer may optionally 

15 set a maximum price. 

16 1. Accessing the list of items sought 

17 Potential bidders access items sought by working through a hierarchy of 

1 8 categories and subcategories or entering search criteria, as for other auctions. A 

19 list of items within the category/subcategory and/or meeting the search criteria 

20 is displayed. The user may then 

21 1.1. Terminate the session on finding no suitable items 

22 1 .2. Revise the search criteria 

23 1.3. Select an item on which to bid 

24 2. If the user selects an item on which that may wish to bid, detailed information 
2 5 about the items is displayed. This item may include the following information: 

26 2.1. Name 

27 2.2. Seller 

28 2.3. Description 

2 9 2.4. Detailed specifications for items 

30 2.5. Delivery requirements 

3 1 2.6. Proposed terms 

32 2.7. Current low bid 

33 3. If the user determines that they should bid, he accesses the bid entry screen from 
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1 the detailed description in Step 2 above. Making a bid consists of entering the 

2 following information: 

3 3.1. New, lower bid 

4 3.2. Comments pertaining to any special terms, features, or conditions 

5 3.3. Attachments containing relevant additional information and any 

6 certifications required by the buyer 

7 4. On receipt ofbid, there are twooptions- either all bids are accepted, or bids are 

8 accepted only after review of information by the buyer. 

9 4.1. Case 1: all bids are accepted 

10 4.1.1. New bid is checked to determine if it is lower than prior bid 

11 4.1.2. If so, then 

12 4.1.2.1. bidder is notified that their bid is currently the lowest 

13 4.1 .2.2. seller is notified of new low bid 

14 4.123. bid database is updated 

15 4.1.3. If not, men 

16 4.1 J. 1. Bidder is notified that their bid is not me lowest 

17 4.1.3.2. Bid screen is displayed so that bidder may lower bid 

18 4.2. Case 2: bids are accepted after review by buyer 

19 4.2.1. Buyer is notified ofbid via email or online message 

20 4-2.2. Buyer accesses complete information on the proposed bid through the 

21 system 

22 4.2.3. Buyer select accept bid or reject bid. 

23 4.2.4. If bid is accepted, then 

2 4 42 A. 1 . Bidder is notified that their bid is currently the lowest 

2 s 4.2.4.2. Bid database is updated 

26 42.5. If bid is not accepted, men 

27 42.5.1. Buyer enters reason for not accepting bid 

28 42.52. Bidder is informed that bid is rejected with reason stated 

29 above 

3 0 42.5.3. Bidder may access the bid screen to revise offer 

31 5. When time period has expired and there have been no bids within a short 

32 specified interval, then 

33 5.1. If at least one bid less than the maximum has been received, then: 
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1 5.1.1. Notify low bidder that their offer was successful 

2 5.1.2, Add transaction to completed deals database 
5.1 .3. Settle with winning bidder- two models: 

5 13.!. Connect or introduce buyer to seller for direct settlement 
5.U.2. Collect money from buyer, deduct fee if any for auction and 
payment services, and convey the remainder to seller. 
52. If no bid less than the maximum has been received, the 

8 5.2.1. Notify buyer 

9 5.22. Allow buyer to revise bid criteria 

10 F, fifif le< * Bid Transaction Bngjng 

11 In a sealed bid system, the buyer publishes or distributes detailed, fixed 

12 specification to a number of potential bidders (who may or may not be 
prequalified). Bidders submit binding bids by a specified deadline, in a specific 
format that allows ready comparison. The competitive bidding process is 
distinguished from the bid and proposal process by the complexity of the 
specifications and the bids. In a simple competitive bid. competition among the 
bidders is along one or two readily quantified dimensions (always including price) 

18 and there is little or no room for variation in me form or specifications of the 

19 offering. Comparison of the bids is elementary. 
The process for posting an item for bid and for qualifying bidders is the 

same as for other transactions as is the method to identify items on which to bid 
either using the hierarchy of categories and subcategories or a search engine. 
1. If the user selects an item, on which he may wish to bid, detailed information 
about the items is displayed. This item may include the following information: 

25 1.1. Name 

26 1.2. Seller 

27 1.3. Description 

28 1.4. Detailed specifications for items including all information necessary to 

29 prepare a bid 

30 1.5. Bid instruction including specification for any documentation the buyer may 

3 1 required with a bid (e.g. proof of bonding or license) 

32 1.6. Notice of any fees for bid registration 

33 1.7. Delivery requirements 
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1 1.8, Proposed tenns 

2 2. After review of the bid requirements, the user may choose not to bid or may enter 

3 a bid. The process for entering a bid consists of preparing a bid package, 

4 including the price offered and any necessary supporting documentation. This 

5 is done by completing an online form, with provision for attachments. The bid 

6 is submitted through the system where it goes into a database of bids that are not 

7 opened to the closing time for the bidding process. 

a 3- At the closing time, all bid packages are conveyed to the buyer. 

9 3.1. If there are no bids, the buyer is offered the opportunity to revise the request 

10 forbids. 

11 3.2. If there are multiple bids, the buyer reviews the bids and selects the lowest 

12 priced qualifying bid. They buyer informs the seller and arranges payment 

13 and delivery in accord with the terms stated in the bid package. 

14 R Order Matching Transaction Engine 

15 In an order-matching system there are many potential buyers. Each posts 

1 6 binding offer to buy (bid amount) or sell (asked amount). The process proceeds in 

17 realtime. The order matching system constantly compares bid and asked and, when 

18 a match is found within a specified spread, the deal is concluded. No accepted offer 

19 can be repudiated, but offers may be withdrawn before a deal is consummated The 
2 0 strike price is posted so that buyers and sellers can modify their o fferings in real time. 
2 1 The items traded are fungible so that price is the only decision. For the market to 
2 2 operate efficiently the items traded must be tightly defined and the terms of sale must 
23 be fixed and determined in advance. This is typically done by the operation or an 

2 4 exchange, with the order-matching engine operating in the background. To insure 

25 that the items traded are well defined, and the terms of sale are rigid example of an 

26 order matching process in stock trading on an exchange. 

27 Users of an order-matching engine are all potential buyers and seller. They 

28 are qualified in advance using a process like that outlined by for auction with the 

29 extension that deposit accounts are frequently required given the speed of 

3 0 transactions in exchange environments. 

31 1. Establish and maintain items to be traded. All functions in this category are 

3 2 reserved to the manager of the exchange or a designee. 

33 To add (Le. "list" and idem), enter 
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1 1.1. Unique item number or symbol 

2 1 2. Description of item (e.g. Sears Class A Common Stock) 

3 1 J. Terms and conditions ownership (e.g. who can own) if any 

4 1 .4, Trading units (e.g. shares, blocks, etc.) 

5 1,5. Additional information as required by the rules of the exchange 

6 To delete (i.e. "delist" and item) 

7 1 .6. Select the item to be deleted 

8 1.7. Confirm deletion 

9 2. On entry to the system, potential buyers and sellers can review the price of the 

10 last transaction of any item, either through a list or a search by item name or 

11 symbol The current .highest asked and lowest bid price are also shown. 

12 3. An offer to sell is posted by entering the following information: 

13 3.1 . Item number or symbol 

14 3.2. Quantity offered 

15 3.3. Proposed price ("asked") 

16 3.4. Seller 

17 33. Offers may be revise at any time prior to consummation of a deal 

18 4. An offer to buy is posted by entering the following information 

19 4. L Item number or symbol 

20 4.2. Quantity offered 

2 1 4.3. Proposed price ("asked") 

22 4.4. Buyer 

23 4.5. Offers may be revised at any time prior to consummation of a deal 

24 5. Offers to buy and sell are constantly reviewed by the software. When there is an 

25 offer to buy and sell at a price within a preset difference. When prices match, 
2 6 buyers and sellers are notified of the transaction, and the transaction is recorded. 

2 7 The display of the last transaction price, the highest bid and the lowest asked 

28 price is updated. 

29 6. The transaction is conveyed to the backend accounting system of the exchange. 

30 fi T Rid and Proposal 

3 1 The bid and proposal process is typically used for procurement of large or 

3 2 complex products or services, in which cost is not the only factor. Cost must be 
3 3 weighed against the buyer's assessment of the quality and suitability of an offering 
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1 and the ability of the bidder to deliver the product or perform the specified services. 

2 The bid and proposal process is conducted between one buyer (possibly 

3 representing a consortium) and many potential sellers, sometimes organized into 

4 teams. The buyer issues specifications that may be general or highly specific, brief 

5 or very lengthy* The specifications may be distributed freely or to a list of qualified 
€ buyers. 

7 With physical RFPs, the size and the associated cost of distribution make it 

8 common practice to advertise the availability of the RFP first, sending copies only 

9 to those that request it Frequently, the requestors are required to supply information 

10 to establish their qualifications to bid. While cost is not an issue in electronic 

1 1 dissemination of RFPs, the model of advertising prior to distribution is still useful in 

12 managing the qualification process. This is addressed as variant (a) is this 

13 description. Variant (b) requires no prequalification. 

14 In a competitive bid on fixed requirements (sealed bid or auction), there is 

15 typically very little communication between buyer and seller between publication of 

16 the request and submission of the bids. The requirements are comparatively simple, 

17 clear, and unambiguous. In contrast, the bid and proposal process may involve 

18 considerable communication between buyer and seller. The process may begin with 

19 a bidders' conference to answer questions about the requirements. Additional 

20 questions from bidders may be accepted, though not all need be answered. 

2 1 Questions and answers may be made available to all bidders or the response may be 

22 in private. This dialog is crucial for two reasons. First, it helps the bidden 

23 understand the requirements and to be responsive in their bids. Second, it is not 

24 unusual for the bidders' questions to identify some point of ambiguity, error, or 

25 contradiction in the specifications, leading to a modification of the RFP. The 
2 6 diveree perspectives of the bidders, and the close attention required on their part to 
2 7 prepare a bid inherently provides an excellent review of the RFP. 

2 8 The initial phase of the RFP process concludes with submission of the bids, 

29 but this is far from die conclusion of the process. Commonly, questions arise from 

30 the review of the proposals. These may relate to a specific submission or have 

31 broader implications, leading to modification of the requirements. The list of 

32 bidders can be culled to the best candidates. These are asked to answer questions 

3 3 about their proposals and to provide additional and clarifying information. 
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1 The process described here is built around the document repository described. 

2 elsewhere in this application. Through this process of refinement, the list of bidders 

3 is narrowed to one or two with whom a contract is negotiated. The process of 

4 negotiation is addressed as a separate transaction type (Negotiation Engine) as it may 

5 be conducted without the bid and proposal process, 
s Variant (A); wfrh prc-flH^ififfltion 

7 1. Software supports the user in creating a web site for the proposal process, 

a Initially this site manages the process for requesting the request for proposal 

9 (RFP), qualifying bidders, and disseminating the RFP. 

10 2. Supported by the system software, the bidder creates and RFP advertisement by 

11 2,1. entering a summary of the RFP, 

12 2.2, entering a summary of the information needed to qualify as a bidder or 

1 3 13. attaching a form (HTML web page or template for paper form) for entering 

14 qualifying information 

15 3. The RFP advertisement includes file transfer software for uploading qualifying 

16 information to the repository. 

17 4. Disseminate RFP advertising 

13 4.1. Post on public bulletin board or 

1 9 4.2. Disseminate via mail to selected users 

20 5. When users access the system, issue them an encryption key and PIN to be used 

2 1 for subsequent uploads and communications to verify their identity. 

22 6. Receive requests for RFP in repository 

23 6.1. Prompt for key 

2 4 6 2. Encrypt submission 

25 63. Upload 

2 6 6.4. Generate receipt - should include an authentication number 

27 7. Disseminate RFP to selected user, either 

28 7.1. Attach to return Email or 

2 9 7.2. Post the RFP in a repository from which qualified prospective bidders may 

3 0 download the file. If the repository model is used, provide notice of the 

3 1 posting via email including any necessary PINs and codes to access the 

32 repository 

33 7.3. When a prospective bidder downloads an RFP, issue an encryption key to be 
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1 used in submitting proposal 

2 8. The RFP site also includes a page through which prospective bidders can submit 

3 questions. Questions and answers arc posted to the site. 

4 9. Updates to the schedule and amendments to the RFP are posted to the site 

5 10* All access to the site is recorded to verify that prospective bidders have received 

6 critical information. Direct contact may be used when it is determined that a 

7 bidder had not accesses the site since critical new information was posted. 

8 11, Bidders prepare their proposal and then upload them to a repository for proposals 

9 using software built into the proposal site* 

10 11.1. Prompt for key 

11 1 1 .2. Encrypt submission 

12 UJ. Upload 

13 11.4. Generate secure hash number to prevent tampering with the 

14 submission 

15 1 1.5. Generate receipt including secure hash number and authentication 

16 code 

17 12. After initial proposals are received, the process moves into a phase commonly 

1 8 termed the <c best and final process" in which fee proposals are reviewed, the list 

1 9 narrowed, and the proposals refined. 

20 12. 1 . Create separate secure environment (i.e. web site with repository) for 

21 each respondent 

22 12.2. Exchange materials through repository (described elsewhere in this 

23 filing) 

24 12.3. Records and receipt each access 

25 12.4. Generate key for revised proposal 

26 12.5. Receive proposal using process in 1 1 

27 12.6. Repeat from step 1 1 as many times as necessary 
28 

2 9 The remainder of the process is completed as a negotiated deal, described below, 

30 Variant B: no ore-Qualification; 

3 1 Proceed as above, beginning with Step 6 and not requiring a key for download of the 

32 RFP. 
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1 H. Negotiation Deal Fnjnn* 

2 An engine for negotiating a deal can be built around the capability of the 

3 system to create a temporary virtual private network through the web. A temporary 

4 network is created for the negotiation. Access to the network is limited to the parties 

5 of the negotiation, their advisors and counsel, and, potentially, arbitrators and 

6 regulators. The members of the negotiating environment have access to the complete 

7 set of tools described in this filing including those for communications (email, 

8 anonymous mail, online chat, threaded dialogs, and audio and video collaboration), 

9 the library of standard contract instruments, the tools for document signature and 
authentication, and the document repository. Using these tools in a secure 

1 1 environment they can negotiate, close, and register a deal. 

12 HG. 19 shows one possible user interface for selecting participation engines 

13 to be made available to group members. The term "participation engine" refers 

14 generally to collaboration tools that provide features beyond merely communicating 

1 5 among group members. Various services such as an on-line survey tool, a DELPHI 

1 6 model tool; brain writing tool; and real-time polling can be provided. 



10 



17 
18 
19 
20 



In online polling or surveying, the person creating the poll uses and 
automated tool (new to this application) to build simultaneously an online 
questionnaire and a database to collect the results. The user builds the questionnaire 

21 by entering a series of questions and an associated data collection widget for each. 

22 The polling tool builds the database and the data entry screen. The data entry 

23 screen consists of two columns. The lea column is a series of questions. The right 



25 


can be provided to respond to the query, including such things as: 


26 


1. 


yes / no radio buttons 


27 


2. 


true / false radio buttons 


28 


3. 


slider with scale from 1-5, 1-10, etc. 


29 


4. 


fill-in- the-blank text box 


30 


5. 


numeric field 


31 


6. 


multiple check boxes (e.g. strongly disagree, disagree, 


32 




agree) 


33 


Other data entry types may be added. 



69 



SUBSTITUTE SHEET (RULE 26) 



CA 02345241 2001-03-22 



W ° 00/17775 PCT/US9M1534 

1 As each question / data collection widget is added, the polling tool creates the 

2 database. The database includes one record per data collection form. Creating the 

3 database structure simply means adding one new field to each record definition for 

4 each question. The type of data collection widget defines the fonnat of the field, as 

5 follows: 

6 1 . yes / no radio buttons: one character field, limited to "y" or V 

7 2. true /false radio buttons: one character field, limited to "y" or "n" 

8 3. slider real number field, with ap p ropri ate range check 

9 4. fill-in-the-blank text box: text box 

10 5 . numeric field: real number or integer 

11 6. multiple check boxes: integer field with range check from 1 to number of 

12 boxes 

13 Every data entry screen provides a "save" and "cancel" button. Save writes to the 

14 database. Cancel exits the entry screen without saving. 

15 The survey, once composed as described above exists as a web page. This 

16 page can be embedded in web applications. It can be made available on a site 

17 available to the entire Internet, on an Intranet, or in a dynamically created 

18 environment Alternatively, it can be distributed via e-mail. When the form is 

19 completed, the submit button transmits the value entered to the database that is 

20 created at the time the form is generated. Access to the database is controlled by the 

2 1 rules of the database system. It may be limited to the individual who creates the 

22 survey form and database, but it may be accessible other users in the survey 

23 c^vetopers organization, as determined by the database administrator. Distribution 

24 of the result of the analysis is at the discretion and control of the individual managing 

25 the survey. This manager may be the individual who creates the survey, but the 
actual creator may be acting on behalf of the survey manager. Results may be kept 
private, posted to the Internet, and intranet, or a collaborative environment, 

2 8 distributed via e-mail within an organization, or, if the information is available, sent 

29 via e-mail to the participants in the survey. 

30 B. Online nriphi ff ng jnft 

31 The online Delphi engine allows real-time coUaboration in estimating or 

32 predicting an outcome that can be expressed numerically. For example, the method 

33 can be used to develop a consensus forecast of grain prices. The method has been 
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1 in used since the 1970s, but has not previously been adapted to online processes. . 

2 One possible method is as follows: 

3 1. Establish the session 

4 1.1. Within an online community, the moderator of the session creates the brain 

5 writing session by entering the following information: 

6 1.1.1. Name of moderator 

7 1.1.2. Title of the session 

8 1.1 .3. Description of the session 

9 1.1 A Background reading as references or attachments 

10 1.1.5. Start date for the session 

11 1.1.6. Scheduled end for the session 

12 1.1.7. Access to the session: 

13 1.1.7.1. URL for access 

14 1.1.7*2. Open to all or invitees only for observation 

15 1.1 .7.3 . Open to all or invitees only for participation 

16 1.1.8. Payment information if required 

17 2. Optionally, the session may be advertised on line 

18 3. If the session is private, invitations with logon keys must be distributed via email, 

19 actual mail, or download 

20 4. Optionally, the moderator may run on online applications and qualification 

21 process 

22 5. Prior to the start of the session, the moderator must describe precisely the value 

23 to be estimated The definition must be completely unambiguous. 

24 6. Each participant connects at the start of the session* On connecting, they question 

25 is posed (e.g. "What will be the price of West Texas intermediate oil in 

26 December?") 

27 7. Each participant enters a number a brief (1 paragraph maximum) explanation of 

28 their reasoning. 

29 8. When the participant is done entering their estimate, they click "Done". 

30 9. Each participant's estimate and explanation is recorded 

31 10. Each participant then sees the summary screen. 
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1 11. Estimates are arrayed graphically from top to bottom of the screen, from lowest . 

2 to highest The value is stated as is the associated comment, but the source of 

3 the comment is not revealed. 

4 12. Participants can review the estimates and enrrmngnfy qe^H «ri flnPnytTK?U8 m gsffl gg 

5 to the author or any comment, or amend their answers. 

6 13. The session terminates when the time expires, or when the moderator determines 

7 that there it is no longer appropriate to continue. The operator may determine 

8 this is based on declining participation or, if participation is high, the moderator 

9 may extend the deadline. 

10 14. Participants and observers may access the final display of estimates, again 

1 1 arrayed from top to bottom, lowest to highest* 

12 C Brain Writing 

1 3 Brain writing is a variant of a method for facilitated group discussion termed 



14 brainstorming. The objective of brainstorming is to maintain the focus of the 

1 5 discussion while encouraging creative input and recognizing the contributions of all 

1 6 members of the group* It seeks to avoid problems with a few individuals dominating 

17 the discussion, with junior staff deferring to senior staff, and with new ideas being 

1 8 abandoned before than can be developed fully. Brain storming has been commonly 

1 9 used since the late 1 960s. Brain writing is a more intense method that relies on joint 
2 0 writing rather than discussion. What is presented here is adaptation of that method 

21 to an online environment. It is believed to be the first such adaptation. 

22 1. Establish the session 



23 1.1. Within an online community, the moderator of the session creates the brain 

2 4 writing session by entering the following information: 

25 1.1.1. Name of moderator 

26 1.1.2. Title of the session 

27 1.1.3. Description of the session 

28 1.1.4. Background reading as references or attachments 

29 1.1.5. Start date for the session 

30 1.1.6. Scheduled end for the session 

31 1.1.7. Access to the session: 

32 1.1.7.1. URLforaccess 

33 1.1 J2* Qpen to all or invitees only for observation 
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1 1.1.7.3. Open to all or invitees only for participation 

2 1.1.8. Payment information if required 

3 2. Optionally, the session may be advertised on line 

4 3, If the session is private, invitations with logon keys must be distributed via email, 

5 actual mail, or download. 

6 4. Optionally, the moderator may ran on online applications and qualification 

7 process 

8 5. Prior to the start of the session, the moderator must list some number (typically 

9 5-10) of questions or hypotheses to be explored. (e.g. M Our company should 

1 0 create a spinoff to develop and commercialize the new breast cancer vaccine**) 

1 1 This may be done by the moderator alone, in consultation with the participants, 

12 or with other outside die session. 

13 6. Each question or hypothesis becomes a "Card". 

14 7. Participants may enter fee session any time after the start A password may be 

1 5 required if the session is not open. 

16 8. On entry into the system, a user if given a card at random . The card consists of 

17 the initial question or hypothesis phis all comments entered on the card by other 

18 participants. 

19 9. After reviewing the card, the participant may add his or her own comments to the 

20 bottom. After entering comments, the participant clicks "Done" to return the 

21 card to the pile. 

22 10. When a participant returns a card to the pile, they received another card, chosen 

23 at random (preferably) or selected by the user. This process continues until the 

24 opt to exit They may reenter at any time up to the conclusion of the session. 

25 11. When a card is returned to the pile, it is become available for assignment to the 

26 next participant The card includes the additions of the most recent participant 

27 1 2. A participant may opt to return the card without addition if he or she has nothing 

28 to add 

29 13. Participants may create new cards when new ideas come to mind. These are 

30 treated in exactly the same way as original cards. 

31 14. Observers may view any card but may not add to them. 

32 15. The moderator may limit participation to a set number at any time so that there 

33 is a sufficient number of cards to keep the participants flilly occupied. 
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1 16. The session terminates when the time expires, or when the moderator determines . 

2 that there it is no longer appropriate to continue. The operator can determine this 

3 based on declining participation or, if participation is high, the moderator may 

4 extend die deadline. 

5 17. The raw canis are distributed at the conclusion to all participants. The moderator 

6 or another individual is charged preparing a summary and arranging follow-up. 

7 FIG* 22 shows one possible scheme for storing brain card writing data 

8 elements. In accordance with one embodiment, each brain writing card comprises 

9 a data structure including the following elements: 

10 1. Brain writing session number: Serially assigned number to differentiate 

1 1 brainwriting sessions. A session is the set of all cards pertaining to a 

12 particular topic. 

13 2. Card number A Serially assigned sequence number 

14 3. Initial Comment : The question or comment used to initiate the discussion 

15 (e.g. tc SAIC should purchase a company that produces Internet server 

16 software** 

17 4. Date and time card started 

18 S. Date and time card closed 

19 6. Comments: A collection (i.e. a set of unlimited length) containing the 
2 0 comments added by participants in the brainwriting session. 

21 7. Date of additional comment Date and time that each additional comment 

22 was added 

23 8. Commented Name or user ID of the person adding each additional 

24 comment Ideally, brainwriting should be anonymous to encourage open 

25 dialog. Accordingly, this field may be omitted from an implementation. 

26 Some or g ani z a tion s, however, may wish to track this information 

27 without making it visible to users, or in some cases to attribute comments. 
2 8 When the user has finished defining the group and specifying its functions, 



29 environment generator 1201a (FIG. 12) creates an environment accessible to the 

30 group members and including the functions specified during the environment 

3 1 definition process. As shown in FIG. 20A, for example, a web page can be created 

32 for the newly created environment, including those functions that were selected by 

33 the user that created die group. All group members arc notified of die existence and 
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1 location of the environment, and each group member can use the functions provided . 

2 in the environment to collaborate on a project or conduct business. 

3 FIG. 20B shows what an environment might look like to a group member 

4 after entering the environment As shown in FIG. 20B, for example, a news banner 

5 announces the latest news for the group. Additionally, specific communication tools, 
€ research tools, transaction engines, and participation engines are made available to 

7 group members, which can be executed by appropriate mouse clicks in accordance 

8 with the inventive principles. According to various inventive principles, each tool 

9 shown on the web page is accessible through a hyperlink to a web-based program that 

1 0 performs predefined functions as set forth above. For example, clicking on "online 

11 catalog" would link the group member to a web page that implements an online 

12 ordering engine as described previously. Users can navigate through the various 

13 tools using conventional web browser features (i.e., forward, backward, etc.). It may 

14 be desirable to implement some or all of such software using server-side scripting or 

1 5 other similar means consistent with the system configuration of FIG. 1 2. 

16 FIG. 21 shows how environment generator 1201a can create multiple 

1 7 environments including virtual private facilities, which can be implemented through 

1 8 web pages that contain hyperlinks to functions available to members of each group 

19 or environment An environment definition software component 21 06 implements 

20 steps 1 101 through 1103 of FIG. 1 1 in order to create one or more environments 

21 2107. (In one embodiment, each group can also be provided with a copy of an 

22 environment generator 2106 in order to create sub-groups that draw on the 

23 applications and directory structure created for the group). As a user identifies group 

2 4 members and selects functions to be provided for the environment in which the group 

25 will collaborate, environment definition component 2106 stores information relating 

26 to the selected members and ftmctions in databases. Each environment can include 

27 a web page (not shown in FIG. 21) and directories, tools and other applications 

28 specific for each created group* 

29 Based on user selections of the type illustrated in FIGS. 13 through 19, 
3 0 environment generator 2106 creates an environment 2107 containing one or more 

3 1 web pages with links to the selected tools. Environment generator 2106 retrieves 

32 information from various information sources including a directory of 

33 communication tools 2101 (e.g., including descriptions of tools and URL/IP 
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1 addresses of web applications to set up each communication tool); directory of 

2 transaction engines 2102 (e.g., including descriptions of transaction engines and the 

3 URL/IP addresses of web-based applications to set up each transaction engine); 

4 directory of research tools 2103 (similar to above); list of global data objects 2104 

5 (e.g., a dictionary of data elements from which die directory of each group can be 

6 composed); and a directory of applications 21 OS (e.g., a description of available 

7 applications and URL/IP addresses of pages to set up access to applications). 



P age 79 of 115 



76 



SUBSTITUTE SHEET (RULE 26) 



CA_2,345 ( 241 _ Page 80 of 11 5 

. ~ 02345mT0Ol-O3-22 * I i teCW- «9 mJM^ji 7 

22-1 1-2000 US 009921934 

SUBSTITUTE PAGE 

1 WjE CLAIMS 

2 1. A method of negotiating a deal over a network of computers, the network 

3 inducting at least one or more computers connected to the Internet, die method comprising the 

4 steps oft 

5 (1) posting, on an electronic list that can be viewed over the Internet, information 

6 regarding one or more offers to form a contract, wherein offers and responses to said offers are 

7 displayed in a parent-daughter spatial relationship on a computer display; 

8 (2) posting on the electronic list one or more responses to the one or mart offers; 

9 (3) researching the one or more responses to determine whether they satisfy one or 

1 0 more contract criteria; 

11 (4) negotiating over the network between at least two parties to accept or modify one 

12 or more of the responses; and 

13 (5) electronically signing a document to consummate the contract 

14 2. (Canceled) 

1 5 3. The method of claim 1> farther comprising the step of sorting the one or more 

1 6 offers and one or more responses according to a user-selected sort order* 

1 7 4. The method of claim 1, wherein steps (1) and (2) are done anonymously, such that 

1 8 each party to the contract cannot determine the identity of the other party to the contract 

19 5. The method of claim 4, further comprising the step of simultaneous revealing the 

20 identity of each party prior to step (5). 

21 6 The method of claim 4, wherein steps (1) and (4) comprise the step of sharing a 

22 single anonymous e-mail alias among a plurality of users. 

23 7. The method of claim 1, ftirther comprising the steps ofi 

2 * C 6 ) registering keywords with an electronic agent that monitors the one or more offers 

25 and providing an e-mail address to be notified upon a keyword match; and 

26 ( ? ) in response to the electronic agent detecting the keyword match, transmitting a 

27 message to the e-mail address provided in step (6). 

28 8. The method of claim 1, wherein step (2) comprises the step of clicking on a 

29 hyperlink linking the information posted in step (1) to a reply cant 

30 9 > T* 0 niethod of claim 7, wherein step (2) comprises the step of requiring the 

3 1 submission of certain information before the reply card will be accepted. 
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1 10, The method of claim 1, wherein steps (3) *od (4) are performed a plurality of 

2 times for a single contract, such that modifications are made to the one or more responses. 

3 11* The method of claim 1, ftartber comprising the step of electronically registering a 

4 plurality of entities that have signatory aofcority and correlating the registered entities with one 
j or more documents to which signatures can be affixed, 

6 12. A method of displaying information on a computer display, comprising the steps 

7 o£ 

8 (1) displaying a first plurality of graphical objects each having a shape of a file folder 

9 comprising a folder face and a labeled tab, wherein the first plurality of graphical objects are 

10 stacked in a cascading arrangement in a front row over a second plurality of graphical objects m 

1 1 a back row, each of the second plurality having a shape of a file folder comprising a folder face 

12 and a labeled tab, wherein only a portion of the second plurality's labeled tahs are visible; and 

13 (2) in response to user activation of a flip tab, changing the graphical objects 

14 displayed in step (1) to show (he second plurality of graphical objects in the front row, 

15 wherein each of die first and second plurality of graphical objects in the front row can be 

16 brought to a foreground position in front of other graphical objects by clicking on a 

17 corresponding labeled tab. 

18 13. The method of claim 12, wherein each of the first and second plurality of 

19 graphical objects has associated therewith one or more functions displayed on the folder face 

20 thereof, wherein user can activate the one or more functions by clicking thereon. 

21 14. A method of creating a user-defined networked environment across a plurality of 

22 computers without requiring system administrator-level privileges, comprising the steps ofi 

23 (1) creating a group hy providing a group identifier, a group description, and by 

24 specifying a plurality of group members entided to use the user-defined networked environment; 

25 (2) selecting a plurality of web-based communication, collaboration, and transaction 

26 tools from a list of available tools, wherein the selected tools are to be made available to the 

27 plurality of group members specified in claim 1 ; and 

28 (3) through the use of co mpute r software, automatically creating the user-defined 

29 networked environment by creating a web page accessible to the plurality of group members 

30 selected in step (1), wherein the web page provides access to the plurality of tools selected in 

31 step (2). 
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1 15. The method of claim 14, wherein step (1) comprises the step of inviting a 

2 plurality of individuals to join the group by fcuunritting an invitation to prospective group 

3 members. 
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1 16. The method of claim 14, wherein step (1) comprises the step of advertising an 

2 invitation to join the group by posting an advertisement for prospective group members, wherein 

3 at least some of the prospective group member* are unknown to the user creating the networked 

4 environment. 

5 17. Tbe method of claim 14, further comprising the step of screening prospective 

6 members that respond to the advertisement in order to determine whether they should be added 

7 to the group. 

8 18. The method of claim 14, further comprising the steps of electronically 

9 collaborating among group members using the user-defined networked environment 

10 19. The method of claim 14, farther comprising the step of destroying the usar- 

11 defined networked environment when it is no longer needed. 

12 20. The method of claim 14, wherein step (2) comprises the step of selecting a 

13 transaction angine that implements an auction to members of the group, 

14 21. The method of claim 14, wherein step (2) comprises the step of selecting a 

15 transaction engine that implements an on-line electronic survey comprising survey questions that 

16 are to be answered electronically by survey participants. 

17 21 The method of claim 14, wherein step (2) comprises me step of selecting a 

18 transaction engine that implements a bid-nnd-proposal too] mat permits group members to 

19 electronically submit bids on one or more proposals. 

20 23 ' ^tbod of claim 14, wherein step (2) comprises the step of selecting an 

21 online ordering engine that porrnita group members to electronically order goods or services in 

22 me user-defined networked environment 

23 24. The method of claim 14, wherein step (2) comprises the step of selecting an 

24 Electronic Data Interchange (EDI) compatible interlace that executes electronic coimneicial 

25 transactions between two or more group members. 

26 25. The method of claim 14, wherein step (2) comprises the step of a selecting an 

27 electronic brain-writing tool that permits participants to brainstorm using electronic idea cards. 

28 26. A system for implementing a user-defined networked environment that can be 

29 created without the need for system adnumatrator-lcvel privileges, wnipriamg: 
a plurality of web browsers executing on the plurality of networked computers; and 
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1 a computer program executing on one ot marc of the plurality of networked computto, 

2 whereto ihe computer program performs the stepaofc 

3 (1) permittiaa a user to create a group comprising a plurality of group members; 

4 (2) permitting the user to select a plurality of web-bascd communication, 

5 collaboration, and transaction tools from a list of available tools, wherein the selected tools are to 

6 be made available to the plurality of group members; and 

7 (3) automatically generating a web page .cccsrible to the plurality of grorm member*, 

8 wherein the web page provides access to the plurality of tools selected in step (2) to the plurality 

9 of group members. 
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